Just a quick post on the Windows Recycle Bin whilst it’s fresh in my mind (also because I posted some findings on Twitter, and will definitely lose them if I want to refer back another time). I figure since I did the testing I should get it down somewhere. Already spent the time to do it so may as well get it down on paper so I don’t have to redo it again another time 🙂
Recently, I was looking at a few different Recycle Bin parsers and thought it was time to con Eric into writing one for his toolkit.
It worked 🙂
I put together a few notes and test data for him, and from there he knocked it out in a few hours.
Of the tools that I tested, most performed well. One had a minor bug in it because Windows updated the format in Win10, but the author has since updated it, so all is well there.
The command line tools generally would parse individual files, rather than a whole directory. Eric’s has the option to do the whole directory rather than having to include a FOR loop. Some were specific to $I files or INFO2 files, but some did both.
If you’re after speed, rifiuti2 seems to be the fastest.
During my testing I noticed something odd, that has probably been recorded elsewhere, but if it hasn’t here it is.
I noticed a lot of $I files in my Recycle Bin that didn’t correspond to active files that I could access through the UI.
I ran a quick test and exported the $I file in FTK Imager, and then restored the corresponding file to its original location. Looking at the recycle bin again I saw that the $I file still remained as an active file but the $R file was no longer there.
The only timestamps for the restored file that were updated to reflect the restore were the Entry Modified and INDX Entry Modified times.
I rebooted the machine to see what would happen and the $I file was still there.
I’m not sure why the $I file is not deleted immediately on the restore. I imagine it’s cleared out at a later stage.
If I deleted an individual file from the recycle bin, both the $I and $R file were marked as deleted in FTK Imager.
I cleared the Recycle Bin, and all the $R files were marked as deleted. I didn’t go through and check all the $I files though, but there were still allocated $I files. Clearing the recycle bin doesn’t appear to track down all $I files under the users Recycle Bin $MFT entry and mark them as deleted.
There could be other reasons why the $I file still remains in the Recycle Bin, so if anyone has any other ideas to test let me know. I’ve noticed this previously on Windows Vista, so it’s entirely possible that this has been the way that Windows has worked for a long time.
If a $I file and $R file exists, the file/folder is (most likely) in the Recycle Bin.
If the $I file exists, and the $R file doesn’t, then the file/folder has probably been restored. There doesn’t appear to be an indication in the $I file that the corresponding file has been restored.
If both are marked as deleted, then the file was deleted from the Recycle Bin.
But most importantly, you can con Eric into making a tool for you if you give him the spec and data.
Yogesh has done some additional testing that’s worth checking out.
4 thoughts on “Quick Post: Notes on the Win10 Recycle Bin”
I’m guessing it doesn’t create a $i file either since it’s just a file move.
Deleting from the command line bypasses recycle bin I think.
Unrelated to $I and $R files. If tiu copy a file to the recycle bin via command line, it does not show up in the gui.
[…] Over on my ThinkDFIR blog, I posted the findings of a quick test in Win10 where I identified $I files allocated in the Recycle Bin, that weren’t accessible via the UI. Initial indications seem to suggest that this is for files or folders that were deleted but then restored. Yogesh Khatri did some additional testing on methods of removing files from the Recycle Bin to see which one would also remove the $I file. Quick Post: Notes on the Win10 Recycle Bin […]
[…] recently posted regarding some testing that he’d conducted, with respect to tools for parsing Windows Recycle […]