Bonjour, chers lecteurs.
Le registre est l'un des systèmes Windows les plus visibles et les plus importants. Il n'y a presque personne qui n'ait entendu parler de lui. Programmant sous Windows depuis environ 20 ans, je pensais tout savoir sur lui. Mais de temps en temps, quelque chose de nouveau apparaît qui me montre à quel point je me trompais. Par conséquent, aujourd'hui, je veux vous parler des façons inhabituelles de travailler avec le registre que j'ai rencontrées lors de recherches sur les rootkits et qui m'ont surpris.
La première histoire. Noms des valeurs et clés de registre
Nous savons tous que sous Windows, il existe des règles pour nommer les objets, qu'il s'agisse de fichiers, de répertoires ou de clés de registre. Les noms de fichiers ne peuvent pas contenir le caractère «\». Les noms ne peuvent pas être vides. Les noms ont des restrictions de longueur, etc.
Involontairement, nous étendons ces restrictions à tous les systèmes Windows et les respectons lorsque nous travaillons avec le registre. Et c'est là que réside notre erreur. Il existe étonnamment peu de restrictions sur le registre lors de la création de noms. Par exemple, dans le nom des valeurs, vous pouvez utiliser le caractère "\"
Surpris? Non? Alors que direz-vous si je vous montre que le symbole «\ 0» peut être utilisé dans le nom d'une valeur? Oui, oui, exactement le caractère nul. Celui qui est traditionnellement utilisé pour indiquer la fin d'une ligne.
Pour cela, nous avons besoin de la fonction NtSetValueKey exportée depuis ntdll.dll
HKEY hKey = 0; RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion\\Run", &hKey); UNICODE_STRING uName; uName.Buffer = L"Test\0Zero"; uName.MaxLen = uName.Length = 9 * sizeof(wchar_t); NTSTATUS status = 0; status = NtSetValueKey( hKey, &uName, 0, REG_SZ, (void*)lpData, DataSize); RegCloseKey(hKey);
Pour exécuter la fonction NtSetValueKey, vous devez disposer des droits d'administrateur. Par conséquent, une valeur avec le nom Test \ 0Zero apparaîtra dans votre registre.
Certains développeurs Microsoft seront également surpris, car l'éditeur de registre standard ne peut pas afficher une valeur de registre aussi inhabituelle.
Deuxième histoire
La deuxième histoire que je vais vous raconter aujourd'hui s'est produite en 2013.
Au début une petite digression. Chez Kaspersky Lab, je fais partie de l'équipe qui crée, entre autres, Kaspersky Rescue Disk. Pour guérir Windows sous Linux, nous devons analyser les fichiers de registre nous-mêmes. Et pour vérifier le bon fonctionnement de ce mécanisme, nous utilisons de nombreux tests. Parmi eux, il y en a un assez simple:
- Sous Windows, nous écrivons des valeurs de test dans le registre.
- Copiez le fichier de ruche du Registre dans le répertoire de test.
- Nous démarrons le programme qui effectue la suppression des valeurs de test.
- Nous chargeons la douille modifiée dans le registre pour vérifier la suppression.
Et un beau jour, nous avons mis à jour le banc de test Windows vers la version 8.1, et le test a cessé de supprimer les valeurs de test. Comment, j'ai été surpris. J'ai copié le fichier avec la ruche de registre sur mon ordinateur de travail - aucune valeur! Ma première pensée: je dois ajouter des clés modifiées au test Flush. Ajout d'un appel à RegFlushKey, redémarrage du test - aucune valeur!
Est-ce que RegFlushKey ne fonctionne pas, je pensais. Mais il s'est avéré que je n'avais que partiellement raison.
L'astuce était que dans Windows 8.1, Microsoft a changé le mécanisme d'enregistrement des modifications dans le registre. Auparavant, toutes les modifications du registre étaient accumulées en mémoire, puis, lorsque la clé était fermée, lorsque RegFlushKey était exécuté ou après un certain temps, le système enregistrait les modifications dans le fichier ruche du registre. Dans Windows 8.1, les modifications au lieu du fichier de bush de registre sont enregistrées dans des fichiers du même nom avec les extensions .LOG, .LOG1 et .LOG2, et mon code ignorait ces fichiers à cette époque.
Dans ces fichiers, les modifications s'accumulent pendant environ une heure. Et ce n'est qu'après cela que Windows commence à intégrer les modifications dans le fichier principal. Cette tâche est appelée rapprochement et démarre soit toutes les 40 minutes, soit à la fermeture de Windows. L'appel de la fonction RegFlushKey ne déclenche pas la tâche de rapprochement. Pour forcer le démarrage de la tâche d'intégration de modification, vous devez appeler ZwSetSystemInformation avec l'argument non documenté SystemRegistryReconciliationInformation.
ZwSetSystemInformation( 0x9b,
Pour exécuter la fonction ZwSetSystemInformation, vous devez disposer des droits d'administrateur. Et l'architecture du fichier exécutable doit correspondre à l'architecture du système. L'appel de cette fonction à partir d'un programme 32 bits sur Windows 64 bits échouera.
Troisième histoire
Il y a quelque temps, nous avons découvert un rootkit qui prescrivait le lancement de son pilote dans le registre. Nos produits ont supprimé les clés de registre correspondantes, mais après le redémarrage, les clés étaient à leur place. On dirait qu'il met ses fonctions de rappel sur les changements de registre et restaure ses clés après nos changements, pensais-je. Mais il s'est avéré que non. Plus précisément, oui. Le rootkit a défini des fonctions de rappel, mais elles n'avaient rien à voir avec la tâche de récupération de clé. Tout a été rendu plus simple et plus élégant.
Le pilote rootkit, au démarrage, a renommé le fichier de la ruche du Registre SYSTEM en HARDWARE. J'ai créé mon fichier SYSTEM et enregistré périodiquement la branche HKLM / System à l'aide de la fonction RegSaveKey. Lors de la sauvegarde, il a restauré ses clés. Lors du redémarrage de Windows, le système a chargé le fichier SYSTEM et lancé le pilote rootkit. C'est beau? Sympa.
Recherché
PS Ici, nous recherchons un
développeur-chercheur dans une équipe qui scie un moteur anti-spam, et nous avons également besoin d'
un ingénieur de test .