HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\TimeZoneKeyName损坏？

Question

我正在尝试确定Windows系统的当前时区.以下代码片段(松散地)基于@MattJohnson在此主题上的答案:当OS显示语言为非英语时获取本地时区标识符

    using (RegistryKey registryKey = Registry.LocalMachine.OpenSubKey(
                                   @"SYSTEM\CurrentControlSet\Control\TimeZoneInformation"))
    {
       if (registryKey != null)
       {
          string windowsTimeZoneId = registryKey.GetValue("TimeZoneKeyName") as string;
          if (string.IsNullOrEmpty(windowsTimeZoneId))
             windowsTimeZoneId = registryKey.GetValue("StandardName") as string;
          if (!string.IsNullOrEmpty(windowsTimeZoneId))
          {
             int i = windowsTimeZoneId.IndexOf('\0');
             if (i != -1)
                windowsTimeZoneId = windowsTimeZoneId.Remove(i);
             return ConvertFromWindowsId(windowsTimeZoneId);
          }
       }
    }

如果我在第一行"if(string.IsNullOrEmpty(windowsTimeZoneId))"上放置一个断点,那么这就是我在Visual Studio调试器中看到的:

这里发生了什么？RegistryKey.GetValue()返回一个盒装字符串,但为什么它没有检测到两个十六进制00字节并在那里终止字符串？

到目前为止,我已经在我的两台电脑上测试了这个.这是运行Windows 7 64位的.另一个运行Windows 7 32位的是相同的,除了它表示返回的字符串的长度是128个字符而不是127个.

使用regedit.exe查看注册表项时看起来很好,只显示"浪漫标准时间".

一些谷歌搜索出现了这个问题https://social.msdn.microsoft.com/Forums/sqlserver/en-US/eca7ad76-c910-46be-8fb9-876c7cde5c69/registry-read-time-zone-info-differ- when-code-build-on-40-framework-on-host-system-win-7-64-bit？forum = csharpgeneral 否则我找不到任何东西.

该程序使用Visual Studio 2012构建,目标是.Net 2.0.

正如你所看到的,我已经添加了代码来考虑这个"腐败"的结果,但是如果有人可以向我解释这里发生了什么,甚至可能甚至如何避免整个问题,我仍然会感激.

编辑:

该程序使用Visual Studio 2012构建,目标是.Net 2.0.

嗯,情节变浓了.那句话并不完全正确.上面显示的代码堆是在为.Net 2.0目标构建的库程序集中,但它是从一个针对.Net 4.0的程序调用的.现在我尝试从一个针对.Net 2.0的程序调用它,并且没有问题,RegistryKey.GetValue()只返回"浪漫标准时间".所以看起来它确实与.Net Framework 4.0有关,正如在MSDN上发布所暗示的那样.

编辑2 - 开始认为这是"正常的"

对于SO来说,这有点偏离主题,但如果有人在Superuser.com上查看我的相关帖子,我会很感激,因为我没有在那里得到即时的满足感,我想得到这个已经解决,所以我知道我是否还应该恐慌.谢谢.

https://superuser.com/questions/859031/possible-malware-modification-of-windows-registry-entry

Answer 1

当在注册表中设置字符串或多字符串值时，Windows 不会检查语义；它只是存储提供的任何二进制内容，长度由程序员指定。这意味着字符串可能会提前以空值终止，或者相反，根本不会以空值终止。（顺便说一下，这确实存在安全隐患：虽然我认为过早的 null 终止可能不会带来风险，但无法处理字符串不是 null 终止的情况的本机代码可能会带来风险。）

根据 Hans（在他删除的答案中）的说法，如果字符串过早以 null 终止，4.x 之前的 .NET 版本将忽略额外的数据，而 4.x 则包含它。这就是为什么您在开始使用 4.x 后才注意到这个问题。

至于为什么这个特定值会过早地以空值终止，这似乎是微软方面的粗心大意。如果删除额外数据，然后更改时区，额外数据会重新出现。所以看来是 Windows 本身在做这件事。这些数据对我来说看起来是随机的，所以我不相信这是故意的。事实上，这在技术上可能构成数据泄露漏洞，尽管可能没有实际影响。

我建议您搜索 null 并在必要时截断字符串。可能存在不存在的情况，例如，如果该条目已被第三方代码修改，或者 MS 最终发布更新并修复了问题，或者当然，如果您在 . NET 2.x。所以你需要处理这两种情况。

（如果我有时间，当我下周回去工作时，我将在虚拟机上安装一个干净的 Windows 副本，并确认问题存在且绝对不存在任何第三方软件。如果是这样，我会考虑报告它 - 我怀疑 MS 会发布补丁，但它可能会在 Windows 的未来版本中得到修复。）