Open files inside Windows Recycle Bin

Question

I've done lots of research on trying to recover files from another user's recycle bin (Windows 10). They can just log in themselves, but I wanted to work on their ticket while they're out of office.

So far, I have figured out their user SID and retrieved their Recycle Bin directory from C:\$Recycle.Bin. The files are no longer hidden system files and look normal, but the file names are all jumbled and corrupt when I try to open them in Microsoft Word (Word docs) or any other types.

Does anyone know how I would "decrypt" these? Is it even worth the time compared to waiting for them to come back and log in?

Thanks!

Answer 1

In C:\$RECYCLE.BIN\S-1-5-21-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxx\ the files aren't copies of the deleted files. Instead, they are files containing enough information for restoring the file.

Deleted file

In this example a file C:\Users\Public\Documents\test.txt containing short plain text is deleted. Now, in $RECYCLE.BIN\<SID> we have a file $IWRIFSD.txt containing:

The filename is a hash based on the metadata and the contents of this file are:

• binary presentation of the file size and permissions
• the original path to the file stored in wide byte chars (thus, the 00 spaces).

Therefore, you probably need either to log in as the user or use some 3rd party recovery tool.

---

Deleted folder

With deleted folders the recovery isn't that tricky. With similar test file inside a folder, test\test.txt:

C:\$RECYCLE.BIN\S-1-5-21-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxx\$RVW70HC>type test.txt
Content to be manually recovered.

Only the folder name gets "jumbled" i.e. replaced with the hash of the metadata, but the names and contents of files seems to be intact.

Answer 2

Ive done some extensive research on this, as it seems, surprisingly, there is very few info available online on how Recycle Bin actually implemented.

Everything is not that hard to grasp. When you delete file in the Bin, it is not actually moved to it.

First, lets take a look at the subfolders of $Recycle.Bin:

• C:\$Recycle.Bin\S-1-5-18 is folder for built-in SYSTEM account
• C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\, starting from 1000 are non-built in user folders. You should first check which one of them is the one you need by typing whoami /all in command prompt to get your SID, or wmic useraccount get name,sid to get all local accounts SIDs, then choose the folder matching with SID.

If you give security rights to your account to all this folders, Explorer might show your deleted files in every folder, however its just Explorer bug. If you navigate to, say, C:\$Recycle.Bin\S-1-5-18 folder and type dir /a, you will see that its actually empty, and only folder that match with your SID contains your deleted files.

Note that even if you are the only user on the PC, you might still have folder C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1000\ that most likely will be empty. Then your actual folder will be ...-1001\. User "1000" seems to be dangling folder for user that was created automatically by Windows on installation or some updates, then deleted. But Recycle.Bin folder wasn't destroyed and just stayed there. I assume that its safe to delete this dangling folder. I'm not so sure about C:\$Recycle.Bin\S-1-5-18, but I'm fairly sure its safe too, as there is no need for OS SYSTEM account to use the Bin, anyway.

So, here is deletion algorithm:

1. System creates hardlink of the deleted file in C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\ folder with the name $RXXXXXX.<file_ext>, where XXXXXX is 6 symbols HASH calculated based on the file contents, as I assume.
2. Metadata file is created in the same folder with the name $IXXXXXX.<file_ext>. I will show you the content of this file later.
3. Original file is deleted, but because of extra hardlink in $Recycle.Bin, actual file's data stays in the same location on the drive as if file where never touched. It is not moved anywhere. This is why each logical volume must have it's own $Recycle.Bin folder, as hardlinks only work within the same volume.

That's about it. Restoration algorithm:

1. Metadata file is read and hardlink of $RXXXXXX.<file_ext> is created based on $IXXXXXX.<file_ext>'s info in original file location, with original file name.
2. Both metadata and backup file are deleted from $Recycle.Bin

Pretty simple, ain't it?

Now, the most interesting part is that metadata file:

0000  02 00 00 00 00 00 00 00  <-- File header (QW)
0008  00 7C 0A 00 00 00 00 00  <-- File size (QW)
0010  90 83 72 44 28 9C D8 01  <-- File deletion date (QW)
0018  18 00 00 00|43 00 3A 00  <-- File path string length (DW)
0020  5C 00 24 00 52 00 65 00  
0028  63 00 79 00 63 00 6C 00
0030  65 00 2E 00 42 00 69 00
0038  6E 00 5C 00 66 00 73 00
0040  73 00 2E 00 65 00 78 00
0048  65 00 00 00|             <-- |Null-terminated path string| (wchar_t)

All values are in Little Endian format.

Header is fixed and its identical for all the files. Be warned that some $I files might have some junk bytes FF FE appear before the Header. I have no idea what are this for, so you should check for full header before reading further.

Deletion date is in FILETIME format and can be converted to usual SYSTEMTIME via FileTimeToSystemTime. It represents 100-nanosecond intervals since January 1, 1601 (UTC).

So it's not super complicated file format, but quite interesting design.

I'm planing to use this info myself by creating custom "garbage collector" for Windows, that I will add to task scheduler to launch periodically and scan\delete files that where deleted more than 24 hours ago, etc. I know that Windows 10 has built-in option for this, but it's not flexible and not reliable (it sometimes leaves metadata files, while only deleteing $R files). Also, I think, previous Windows versions doesn't have this feature at all.

I encourage you to experiment with this too! For example, your program might save metadata info of all files it removes into some database, so you would have full history of all files you ever deleted!