HKLM \ SYSTEM \ CurrentControlSet \ Control \ TimeZoneInformation \ TimeZoneKeyName endommagé?

J’essaie de déterminer le fuseau horaire actuel pour un système Windows. L’extrait de code suivant est (vaguement) basé sur la réponse de @MattJohnson sur ce sujet: Obtention d’un identificateur de fuseau horaire local lorsque la langue d’affichage du système d’exploitation n’est pas l’anglais

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

Si je place un point d’arrêt sur la première ligne “if (ssortingng.IsNullOrEmpty (windowsTimeZoneId))”, alors c’est ce que je vois dans le débogueur de Visual Studio:

entrer la description de l'image ici

Qu’est-ce qui se passe ici? RegistryKey.GetValue () renvoie une chaîne en boîte, mais pourquoi ne détecte-t-il pas les deux octets hexadécimaux et y termine-t-il la chaîne?

Jusqu’à présent, j’ai testé cela sur deux de mes PC. Ceci est de celui qui exécute Windows 7 64 bits. L’autre, exécutant Windows 7 32 bits, est le même sauf que la longueur de la chaîne renvoyée est de 128 caractères au lieu de 127.

Lorsque vous regardez l’entrée de registre avec regedit.exe, cela semble correct, affichant uniquement “Romance Standard Time”.

Un peu de recherche sur Google a mis à jour cette question quand-code-build-sur-40-framework-sur-l’hôte-system-win-7-64-bit? forum = csharpgeneral Sinon, je ne trouve rien.

Le programme est en cours de construction avec Visual Studio 2012 et cible le .Net 2.0.

Comme vous pouvez le voir, j’ai ajouté du code pour prendre en compte ce résultat “corrompu”, mais j’apprécierais quand même que quelqu’un puisse m’expliquer ce qui se passe ici, et peut-être même comment éviter tout le problème.

MODIFIER:

Le programme est en cours de construction avec Visual Studio 2012 et cible le .Net 2.0.

Hmm, l’insortinggue s’épaissit. Cette déclaration n’était pas totalement correcte. Le tronçon de code indiqué ci-dessus se trouve dans un assemblage de bibliothèque conçu pour cibler .Net 2.0, mais il était appelé depuis un programme ciblant .Net 4.0. Maintenant, j’ai essayé de l’appeler depuis un programme qui cible .Net 2.0, et il n’y a pas de problème, RegistryKey.GetValue () renvoie simplement “Romance Standard Time”. Il semble donc que cela ait quelque chose à voir avec .Net Framework 4.0, comme l’implique la publication sur MSDN.

EDIT 2 – commence à penser que c’est “normal”

Ceci est un peu hors sujet pour SO, mais j’apprécierais que quelqu’un jette un coup d’oeil à ma publication sur Superuser.com, car je ne reçois pas de gratification instantanée là-bas, et j’aimerais résolu donc je sais si je devrais encore être paniqué ou non. Merci.

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

Lorsqu’une valeur de chaîne ou de chaîne multiple est définie dans le registre, Windows ne vérifie pas la sémantique; il stocke simplement le contenu binary fourni, avec la longueur spécifiée par le programmeur. Cela signifie qu’une chaîne peut être prématurément terminée par une valeur null, ou inversement, ne pas être terminée par une nullité. (Cela a des implications de sécurité, soit dit en passant: bien que je ne pense pas que la terminaison null prématurée est susceptible de poser un risque, le code natif ne parvient pas à gérer le cas où la chaîne n’est pas terminée par null).

Selon Hans (dans sa réponse supprimée), les versions de .NET antérieures à 4.x ignoreraient les données supplémentaires si la chaîne est prématurément terminée par un caractère nul, alors que 4.x l’inclut. Donc, c’est la raison pour laquelle vous avez seulement remarqué le problème une fois que vous avez commencé à utiliser 4.x.

Quant à savoir pourquoi cette valeur particulière est prématurément annulée, cela semble être une négligence de la part de Microsoft. Si vous supprimez les données supplémentaires, puis modifiez le fuseau horaire, les données supplémentaires réapparaissent. Il semble donc que Windows lui-même le fasse. Les données me semblent aléatoires, donc je ne crois pas que ce soit intentionnel. En fait, cela peut techniquement constituer une vulnérabilité d’exposition aux données, bien qu’il n’y ait probablement pas d’impact pratique.

Je vous suggère de rechercher un null et de tronquer la chaîne si nécessaire. Il peut y avoir des situations où il n’y en a pas une, par exemple, si l’entrée a été modifiée par un code tiers ou si MS émet finalement une mise à jour et corrige le problème, ou, bien sûr, si vous exécutez. NET 2.x. Vous devrez donc gérer les deux cas.

(Si j’ai le temps, lorsque je retournerai au travail la semaine prochaine, j’installe une copie propre de Windows sur une machine virtuelle et confirme que le problème existe avec absolument aucun logiciel tiers présent. it – Je doute que MS publiera un correctif, mais il pourrait être corrigé dans une future version de Windows.)