.NET 了解其他进程的内存/从其他进程读取变量

Question

我目前正在研究一个主题，老实说，我缺乏知识，甚至无法确定它是否可能。

我想知道当我没有源/PDB 时是否可以理解 .NET 应用程序的进程内存。理解我的意思是，如果我找到一些起点，比如已知的字符串值，我是否可以重建一个对象图。

我们希望保护从加密配置文件反序列化的程序配置。它在内存中是未加密的。配置图中的单个值并不是真正的秘密，但图本身是有价值的。

问题是是否可以仅从进程内存中重建图形？

鉴于攻击者知道如何使用 dnSpy 之类的东西来重建程序集（我们也在磁盘上保护）并且我们不想混淆配置程序集（这需要进行大量更改），攻击者可以根据我们进程的原始内存重构或理解实例？

我尝试对此进行研究，但找不到正确的方向/好的关键字。

我知道存在诸如 CheatEngine 之类的工具，或者我可以简单地转储整个内存并尝试理解这一点。

但我想了解是否有 .NET 工具可以自动执行该过程：

1. 使用配置类读取反编译的程序集
2. 附加到进程并转储内存
3. 理解位和字节，并结合反编译的类来重构实例层次结构

我的主要目标是决定是否需要对内存配置图进行额外保护。如果重建图形不容易，那么我认为不需要它。但如果它像反编译 .NET 应用程序的源代码一样简单，我认为需要一些保护。

Answer 1

“当我没有源/PDB 时，可以理解 .NET 应用程序的进程内存。”

是的，这是可能的。在 .NET 中有一个称为垃圾收集的概念。垃圾收集器需要知道内存的样子，否则它无法完成他的工作。这需要在客户的机器上工作，这些机器没有 PDB，也没有源代码。

有一个名为 MSCORDACWKS 的 DLL，它是 Microsoft（可能）的 MS，.NET 的 COR 和“数据访问控制”的 DAC，以及“工作站”的 WKS。此名称中的 DAC 正是您所需要的。

通常您自己不会这样做，而是使用调试器 (Micosoft WinDbg) 和知道如何处理 DAC 以了解内存的 .NET 扩展 (SOS)。

有关这些主题的示例和其他问题，请参阅 windbg 和 sos。事实上，这很容易。尝试!dumpheap -stat 获取所有 .NET 对象的列表。

问题是是否可以仅从进程内存中重建图形？

如果您愿意，可以使用!gcroot 开始构建对象图。

对于对象图，您最好查看构建此类图的现有工具，例如 Jetbrains dotMemory 等内存泄漏工具。

配置图中的单个值并不是真正的秘密，但图本身是有价值的。

这可能是在代码中调用 GC.Collect() 以强制收集 garbe 的情况，从而使图形消失。但是，使用调试器可以在调用之前停止进程。

是否需要对内存配置图进行额外保护。

恕我直言，是的。并以 C++ 等本地语言实现。