☰

打开 Windows 回收站内的文件

tag-icon • tag-icon windows filesystems files data-recovery
打开 Windows 回收站内的文件

我做了很多研究，尝试从其他用户的回收站 (Windows 10) 恢复文件。他们自己登录就可以了，但我想在他们不在办公室时处理他们的工单。

到目前为止，我已经找出了他们的用户 SID，并从 C:\$Recycle.Bin 中检索了他们的回收站目录。这些文件不再是隐藏的系统文件，看起来正常，但当我尝试在 Microsoft Word（Word 文档）或任何其他类型的文件中打开它们时，文件名全都乱七八糟且损坏。

有人知道我该如何“解密”这些吗？与等待他们回来登录相比，这是否值得花时间？

谢谢！

答案1

这些文件中C:\$RECYCLE.BIN\S-1-5-21-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxx\并不是被删除文件的副本。相反，它们是包含足够信息以用于恢复文件的文件。

已删除文件

C:\Users\Public\Documents\test.txt在此示例中，删除了一个包含简短纯文本的文件。现在，$RECYCLE.BIN\<SID>我们有一个$IWRIFSD.txt包含以下内容的文件：

$IWRIFSD.txt 的 HxD

文件名是基于元数据的哈希值，该文件的内容是：

  • 文件大小和权限的二进制表示
  • 以宽字节字符（即空格）存储的文件原始路径00。

因此，您可能需要以用户身份登录或使用某些第三方恢复工具。

已删除文件夹

对于已删除的文件夹，恢复并不那么困难。对于文件夹中的类似测试文件，test\test.txt：

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

只有文件夹名称变得“混乱”，即被元数据的哈希值替换，但文件的名称和内容似乎是完整的。

答案2

我对此进行了广泛的研究，但令人惊讶的是，网上关于回收站实际如何实现的信息却很少。

一切都没有那么难掌握。当你删除垃圾箱中的文件时，它实际上并没有被移动到垃圾箱中。

首先，让我们看一下子文件夹$Recycle.Bin：

  • C:\$Recycle.Bin\S-1-5-18是内置系统帐户的文件夹
  • C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\，从 1000 开始都是非内置用户文件夹。您应该首先通过whoami /all在命令提示符中输入来获取您的 SID 或wmic useraccount get name,sid获取所有本地帐户 SID 来检查哪一个是您需要的，然后选择与 SID 匹配的文件夹。

如果您将所有这些文件夹的安全权限授予您的帐户，Explorer 可能会在每个文件夹中显示您已删除的文件，但这只是 Explorer 错误。如果您导航到C:\$Recycle.Bin\S-1-5-18文件夹并键入dir /a，您将看到它实际上是空的，并且只有与您的 SID 匹配的文件夹才包含您已删除的文件。

请注意，即使您是 PC 上的唯一用户，您仍可能有一个C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1000\很可能是空的文件夹。那么您的实际文件夹将是...-1001\。用户“1000”似乎是 Windows 在安装或某些更新时自动创建的用户的悬空文件夹，然后被删除。但Recycle.Bin文件夹没有被销毁，只是留在那里。我认为删除这个悬空文件夹是安全的。我不太确定C:\$Recycle.Bin\S-1-5-18，但我相当确定它也是安全的，因为无论如何，OS SYSTEM 帐户都不需要使用 Bin。

因此，删除算法如下：

  1. 系统创建硬链接已删除文件位于C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\名为的文件夹中$RXXXXXX.<file_ext>，其中XXXXXX是根据文件内容计算出的 6 个符号 HASH，正如我所假设的。
  2. 元数据文件在同一个文件夹中创建，名称为$IXXXXXX.<file_ext>。稍后我将向您展示此文件的内容。
  3. 原始文件被删除，但由于 中的额外硬链接$Recycle.Bin，实际文件的数据仍保留在驱动器上的同一位置，就像文件从未被触碰过一样。它没有被移动到任何地方。这就是为什么每个逻辑卷必须有自己的$Recycle.Bin文件夹，因为硬链接只能在同一卷内工作。

就是这样。恢复算法：

  1. 读取元数据文件并$RXXXXXX.<file_ext>根据$IXXXXXX.<file_ext>原始文件位置中的信息和原始文件名创建硬链接。
  2. 元数据和备份文件均从中删除$Recycle.Bin

很简单，不是吗？

现在，最有趣的部分是元数据文件：

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)

所有值小端序格式。

标头是固定的，并且对于所有文件都是相同的。请注意，某些$I文件可能在标头之前出现一些垃圾字节FF FE。我不知道这是做什么用的，所以在继续阅读之前，您应该检查完整的标头。

删除日期为文件时间格式，并可以转换为通常系统时间通过文件时间至系统时间。它代表自 1601 年 1 月 1 日（UTC）以来的 100 纳秒间隔。

所以它不是超级复杂的文件格式，但设计相当有趣。

我计划自己使用这些信息，为 Windows 创建自定义“垃圾收集器”，将其添加到任务计划程序中，定期启动并扫描\删除 24 小时前删除的文件等。我知道 Windows 10 有内置选项，但它不灵活也不可靠（它有时会留下元数据文件，而只删除$R文件）。此外，我认为以前的 Windows 版本根本没有此功能。

我鼓励您也尝试一下！例如，您的程序可能会将其删除的所有文件的元数据信息保存到某个数据库中，这样您就可以拥有所有删除过的文件的完整历史记录！

相关内容