我最近不得不阅读一些恶意软件报告和相关日志，以确认恶意软件检测和随后的 Windows 资产感染。日志清楚地显示.dll了用户AppData文件夹中的文件。这些文件的名称与通常在 中找到的 s.dll相同，例如..dllsystem32cryptbase.dll
我知道在这个特定的例子中，这绝对是恶意软件，而对流氓.dlls 的解包是恶意软件正常过程的一部分。我在聊天中询问了这个问题，并被告知对于这种行为唯一真正可信的解释是恶意软件（就像在这种情况下一样）或非常糟糕的编程实践，即使在这种情况下，这种情况也很少见。
我的问题是双重的；是否存在由于恶意软件或编程不良以外的任何原因在用户文件夹中找到.dll与 standard 同名的文件的情况？system32 .dllAppData
此外，将.dll在 中找到AppData并看似是文件副本的.dll文件system32视为妥协指标是否公平？
由于 Microsoft 已调整该文件夹的默认权限Program Files，因此许多开发人员已将其AppData作为其代码的替代位置。以这种方式安装的应用程序的逻辑可以在不需要提升或管理员级别访问权限的情况下进行更新。（例如，谷歌浏览器就是这样做的）。
这也意味着，有时，您会在路径system32下的某个文件夹中找到通常存在于文件夹中的合法库。AppData这些通常是由应用程序本身维护和更新的运行时组件（如 MSVCRT、GDI+ 或 capicom）（通常是因为它们需要特定版本才能工作，但有时因为它们是作为用户组件而不是系统组件推送的并且需要在没有海拔的情况下部署）。
这并不意味着您应该在那里找到属于操作系统的库：没有正当理由可以在那里找到 schannel.dll，因为维护该库的唯一应用程序是操作系统。
因此，与 dllAppData同名的 dll不会system32自动被怀疑。
虽然不适合分发，但有人可能使用%appdata%系统库路径的另一个原因是运行时匀场。
具体来说：如果我想对给定的 API 合同验证（一个常见的例子是malloc/ free，但这已经由 AppVerifier 管理）或一般使用分析进行运行时检查，我可以编写一个执行验证的 shim 层，然后通过到合法的系统库。
通常，系统库应位于适当的系统或SXS路径中。所有拥有Windows 徽标认证的人都将遵守这一点，但许多应用程序在未经认证的情况下分发。
如果您实际上覆盖了 Windows 的默认 DLL，我会称之为糟糕的编程。将它们放在另一个位置不是System32一种方法：
如果软件制作精良，它会将 DLL 放在AppData其安装目录中，而不是放在System32.
如果恶意软件制作精良，它会将 DLL 放入System32.