Question

这里关于托管环境中内存分配的大多数答案都说“你不需要为这些事情烦恼，让平台处理它”＃34;。事实上，在某些情况下你需要担心这些事情。我有一个对象列表，在内存转储的情况下，我不希望在连续的连续地址行上顺序分配。我希望他们分散。是否有任何方法（技巧或黑客会做）确保对象不按顺序分配，并且不能被识别为内存转储中的序列？谢谢！

编辑：这样做的原因是我试图规避MySQL for .NET要求我将敏感数据作为连接字符串传递的方式。我的想法是将所有内容保存在分散的char列表中，然后在connection.Open（）之前组装它，并在之后立即处理它。有没有更好的办法？我宁愿不将数据库凭据保存在内存中。

结论：通过散布来保护敏感数据不受内存转储的影响似乎是不可能的。在我的具体情况下，我将尽我所能使用SecureString，并将寻找其他方法不将未加密的密码暴露给MySQL。

更新：经过一番挖掘，这就是我最终要做的事情：我的所有SQL都由本地服务执行，帐户仅限于存储过程和localhost。为了请求SP调用，客户端必须通过SHA512哈希密码+ salt进行身份验证。在客户端上，密码从文本框中的char读取char，并附加到安全字符串，然后用system pass char替换文本。然后对安全字符串进行哈希处理，并将原始数据清零，如下所示：

public static string GetSHA512(SecureString secureInput)
    {
        if (secureInput == null)
            throw new ArgumentNullException("securePassword");

        IntPtr unmanagedString = IntPtr.Zero;
        byte[] dataUnmanaged = new byte[secureInput.Length];
        try
        {
            unmanagedString = Marshal.SecureStringToGlobalAllocAnsi(secureInput);
            Marshal.Copy(unmanagedString, dataUnmanaged, 0, dataUnmanaged.Length);

            using (SHA512 shaM = new SHA512Managed())
            {
                byte[] hash = shaM.ComputeHash(dataUnmanaged);
                int i = 0;
                while (i < dataUnmanaged.Length)
                {
                    dataUnmanaged[i] = 0;
                    i++;
                }
                StringBuilder hex = new StringBuilder(hash.Length * 2);
                foreach (byte b in hash)
                    hex.AppendFormat("{0:x2}", b);
                return hex.ToString();
            }
        }
        finally
        {
            int i = 0;
            while (i < dataUnmanaged.Length)
            {
                dataUnmanaged[i] = 0;
                i++;
            }
            Marshal.ZeroFreeGlobalAllocAnsi(unmanagedString);
        }
    }

生成的哈希值随机盐进一步散列并发送到服务以与盐一起进行确认。服务使用盐重新散列其散列传递并进行比较。一旦批准，通过不断更改客户端和服务器跟踪的唯一会话ID进行进一步的身份验证。任何劫持和会话都会立即失效。这样，密码只使用一次，仅传输双线，并尽可能短的时间存储在SecureString中。这是我能想到的最好的。如果有新的东西弹出来，我会进一步更新，感谢大家。

Answer 1

你想通过这个来实现什么目标？

如果是安全性，那么您可以加密您的数据/属性，或者使用SecureStrings就足够了。 GC就是优化内存，而不是将其分段（这实际上就是你所要求的）。

Answer 2

内存布局

由于.NET中列表的内部结构，将.NET对象移动到内存中的随机位置没有任何好处。实际上，您的对象可能已经处于＆＃34;随机＆＃34;地址和垃圾收集器可以随时更改（基于内存需求，而不是由于列表的排序）。

唯一的例外是数组，它们被分配为一个块。确切地说，这些数组将成为问题，因为......

在内部，列表是一个＆＃34;指针数组＆＃34;对象，如此独立于对象所在的位置，一旦有人访问该数组，他就能够按顺序访问所有对象。

下图有望说明这一点：

使用windbg调试器和名为sos的.NET扩展，以下命令可以很容易地找到一个数组并在其中打印对象：

!dumpheap -type List
!dumparray
!dumpobj

在您的情况下，使用SecureString（已经由其他人提及）将确保密码在内存中加密，没有人可以轻松（它仍然可以）显示它。

覆盖内存

关于评论中的后续问题

如果设置myByteArray [n] = 0，可以告诉我吗？实际上将前一个值清零，或者为0分配新内存并存储对它的引用，而n处的原始值仍然位于某个等待GC的位置？这与我的问题有关。

让我们编写以下程序：

using System;

namespace OverwriteValuesInMemory
{
    class Program
    {
        static void Main()
        {
            // Ensure we have it on the heap
            var program = new Program();
            program.FillAndRefill();
            Console.WriteLine("Create a dump now");
            Console.ReadLine();
            // Access to prevent it from being optimized away
            program.nonboxed[0]=0;
        }

        const int M16 = 16 * 1024 * 1024;
        byte[] nonboxed = new byte[M16];
        object[] boxed = new object[M16];

        void FillAndRefill()
        { 
            Fill(nonboxed, 42);
            Fill(boxed, 23);
            Fill(nonboxed, 0x42);
            Fill(boxed, 0x23);
        }

        private void Fill(object[] array, int value)
        {
            for (int i = 0; i < array.Length; ++i)
                array[i] = value;
        }

        private void Fill(byte[] array, byte value)
        {
            for (int i = 0; i < array.Length; ++i)
                array[i] = value;
        }
    }
}

Ans然后让它用WinDbg + SOS进行调试。某些命令的输出可能会缩短，因为它对结果并不重要，但我想要包含命令以使其自包含：

0:005> .symfix
0:005> .reload
0:005> .loadby sos clr
0:005> ~0s

我们可以在堆栈上找到对Program的引用

0:000> !dso
[...]
0042EE4C 02553128 OverwriteValuesInMemory.Program
[...]

或者，在堆中的所有对象中搜索

0:000> !dumpheap -type Program
 Address       MT     Size
02553128 001c4d44       16

查看对象的详细信息

0:000> !do 02553128
Name:        OverwriteValuesInMemory.Program
MethodTable: 001c4d44
EEClass:     001c1394
Size:        16(0x10) bytes
File:        E:\Projekte\SVN\HelloWorlds\OverwriteValuesInMemory\OverwriteValuesInMemory\bin\Release\OverwriteValuesInMemory.exe
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
70cd35fc  4000002        4        System.Byte[]  0 instance 04821010 nonboxed
70cced0c  4000003        8      System.Object[]  0 instance 06981010 boxed

我们找到了盒装和非盒装值的2个成员，我们可以在原始内存中检查它们。非盒子数组的值直接在里面：

0:000> db 04821010 L20
04821010  fc 35 cd 70 00 00 00 01-42 42 42 42 42 42 42 42  .5.p....BBBBBBBB
04821020  42 42 42 42 42 42 42 42-42 42 42 42 42 42 42 42  BBBBBBBBBBBBBBBB

虽然盒装的情况并非如此：

0:000> db 06981010 L20
06981010  0c ed cc 70 00 00 00 01-d8 58 bd 1a e4 58 bd 1a  ...p.....X...X..
06981020  f0 58 bd 1a fc 58 bd 1a-08 59 bd 1a 14 59 bd 1a  .X...X...Y...Y..

查看指针大小的盒装值，我们看到距离为0x0C（12）的值，这表明该对象有一些元数据开销。

0:000> dp 06981010 L10
06981010  70cced0c 01000000 1abd58d8 1abd58e4
06981020  1abd58f0 1abd58fc 1abd5908 1abd5914
06981030  1abd5920 1abd592c 1abd5938 1abd5944
06981040  1abd5950 1abd595c 1abd5968 1abd5974

查看第一个给出的预期值为35（0x23）：

0:000> !do 1abd58d8
Name:        System.Int32
MethodTable: 70cd07a0
EEClass:     7090fd30
Size:        12(0xc) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
70cd07a0  400055f        4         System.Int32  1 instance       35 m_value

因此Program仅引用最后设置的值。这是预料之中的。但记忆呢？旧的价值观是否潜伏在等待垃圾收集？ WinDbg恕我直言不是一个很好的统计程序，所以我使用了HxD，它提供了以下统计数据：

结论：非盒装值被覆盖，而盒装值则不被覆盖。

C＃确保List <t>中元素的混洗内存分配

2 个答案:

内存布局

覆盖内存