Реестр Windows часто воспринимается как единый монолитный массив настроек, который система держит где-то "в глубине". На деле реестр - это прежде всего физическая структура: набор отдельных файлов, лежащих в каталоге C:\Windows\System32\config и в профилях пользователей. Каждый файл называется кустом, или хайвом, и содержит самостоятельную часть конфигурации с собственной историей изменений, журналом транзакций и правилами доступа. Логическое дерево ветвей HKLM, HKCU и HKU, которое рисует regedit, является виртуальной сборкой, смонтированной поверх этих файлов в момент загрузки. Понимание двухуровневой природы реестра - физические файлы плюс виртуальное дерево - объясняет поведение системы при повреждениях, смысл механизма Last Known Good, технику офлайн-правок через reg load и большую часть приёмов аудита и форензики.
Файлы в System32\config как физический фундамент реестра
Главное хранилище системных кустов - каталог C:\Windows\System32\config. В нём лежат несколько файлов без расширений, и каждый из них - отдельная база данных со своим назначением.
Файл SAM хранит базу локальных учётных записей: имена пользователей, идентификаторы SID, хеши паролей и сведения о членстве в группах. Именно этот файл обращает на себя внимание исследователей безопасности, потому что в нём сосредоточены криптографические отпечатки локальных паролей. Рядом исторически стоит файл SECURITY: внутри него живут секреты LSA, кэшированные учётные данные доменных входов, локальные политики безопасности и параметры аудита. Файл SOFTWARE - самый объёмный обычно: там параметры операционной системы прикладного слоя и установленных программ, привязки расширений, пути установки, лицензионные данные. Файл SYSTEM содержит конфигурацию ядра и загрузки: список драйверов с режимами старта, службы, сетевые параметры низкого уровня и наборы ControlSet, о которых речь ниже. Наконец, DEFAULT - это профиль системной учётной записи .DEFAULT, шаблон настроек, активный до входа пользователя, на этапе экрана приветствия.
Пользовательские данные хранятся отдельно. В каждом папке профиля C:\Users\Имя лежит NTUSER.DAT - личный куст пользователя с настройками рабочего стола, приложений и среды. В скрытом подкаталоге AppData\Local\Microsoft\Windows находится UsrClass.dat, добавленный начиная с Windows Vista: в него вынесли ассоциации файлов и регистрации COM-классов пользовательского уровня, чтобы ослабленные права приложений не требовали доступа к системной ветви HKLM\SOFTWARE\Classes.
Формат хайва - бинарная структура с сигнатурой "regf" в начале, разбитая на блоки-ячейки по 4096 байт, с ключами, значениями и индексами. Это полноценная файловая база данных, а не плоский текст.
Виртуальное дерево из HKLM, HKCU, HKU и кто на что указывает
Когда система загружается, Configuration Manager ядра поднимает файлы из config в память и выставляет их в объектном пространстве имён как корневые разделы. Отсюда важное следствие: HKLM\SOFTWARE - это не "ветка реестра" сама по себе, а просто отражение содержимого файла SOFTWARE. Открывая HKLM\SYSTEM, администратор смотрит внутрь файла SYSTEM. Отображение не одностороннее: любая запись в раздел попадает в соответствующий файл.
Интереснее устроены ветви, связанные с пользователями. HKCU - не файл и не раздел в привычном смысле, а указатель: в момент входа система монтирует NTUSER.DAT вошедшего пользователя под HKU\<SID>, а HKCU становится символической ссылкой на этот конкретный поддерево. Если в систему вошло двое (интерактивная сессия и служба с профилем), в HKU будет несколько разделов с SID, и HKCU каждого процесса указывает на свой. Раздел HKU\.DEFAULT, в свою очередь, отражает файл DEFAULT из config - настройки, под которыми работает экран входа. А HKCU закрытого ранее сеанса просто исчезает из HKU, когда профиль выгружается.
HKCR тоже виртуален: это объединённое представление HKLM\SOFTWARE\Classes и ассоциаций из UsrClass.dat текущего пользователя, причём пользовательские записи перекрывают системные. Такое разделение позволило устанавливать обработчики расширений без прав администратора.
ControlSet001, ControlSet002 и машина отката конфигурации
Внутри файла SYSTEM выделяется особый массив: разделы ControlSet001, ControlSet002 и иногда ControlSet003. Каждый - полный слепок конфигурации драйверов и служб. Активный набор определяется значением Current в разделе HKLM\SYSTEM\Select, а CurrentControlSet - вовсе не отдельный куст, а симлинк на текущий ControlSet. Писать в CurrentControlSet - значит писать в активный набор, какой бы номер у него ни был.
Здесь скрыт элегантный механизм Last Known Good. При успешном входе первого пользователя после загрузки система копирует активный набор в резервный слот и помечает его как "последняя заведомо хорошая конфигурация". Если следующая загрузка не дошла до входа из-за свежеустановленного драйвера, меню восстановления предлагает старт с Last Known Good: система поднимет резервный ControlSet вместо испорченного. Поэтому эксперименты с драйверами редко бесповоротно ломают загрузку. Важный нюанс: смена активного набора фиксируется именно успешным входом, поэтому цикл "поломал - не вошёл - откатил" работает, а вот повреждения, внесённые после входа, в резервный набор не проникают.
Зачем дробить единую базу на файлы ради транзакций, журналов и блокировок
Разделение реестра на отдельные файлы - не архитектурная прихоть, а инженерное решение. Во-первых, гранулярность блокировки и загрузки: SAM и SECURITY открываются только доверенным компонентам LSASS, SOFTWARE доступна шире, а NTUSER.DAT вообще подключается и отключается по мере входов пользователей. Один монолитный файл не позволил бы ни раздельного монтирования, ни дифференцированных ACL.
Во-вторых, надёжность. Реестр транзакционен: рядом с каждым кустом в config лежат сопровождающие файлы - SYSTEM.LOG1, SYSTEM.LOG2 и аналогичные для остальных. Изменения сначала попадают в журнал, затем в тело хайва; двойное журналирование защищает от обрыва записи посередине. Нестойкие данные, например текущая конфигурация оборудования сеанса, вообще не пишутся в файлы - они живут только в памяти, что видно по неустойчивым ключам вроде HKLM\HARDWARE. Кусты-копии SYSTEM.alt и копии RegBack (каталог config\RegBack, где раньше лежали периодические резервы хайвов) - ещё один слой страховки.
Физическая отдельность кустов даёт и оперативный приём: офлайн-правки. Командой reg load HKLM\Temp D:\Repair\SOFTWARE администратор монтирует файл куста с другого диска или образа под временным именем, правит содержимое и выгружает через reg unload. Профиль уволившегося сотрудника правится тем же способом через reg load его NTUSER.DAT под HKU. Ровно наоборот работает reg.exe save HKLM\SYSTEM C:\Backup\system.hiv - бинарный снимок куста, пригодный для восстановления и анализа.
Повреждённые кусты, диагностика и ремонт через System Volume Information
Когда система отказывается грузиться с ошибкой вида остановки, указывающей на испорченный SYSTEM или SOFTWARE, лечение опирается на физическую модель: нужно вернуть целостный файл. Первый кандидат - содержимое config\RegBack, если он не пуст: копия хайва копируется поверх битого в среде восстановления, где системные файлы не заблокированы. Второй источник - теневые копии тома: точки восстановления, хранимые в System Volume Information, содержат прежние версии всего каталога config. Смонтировав снимок или загрузившись с установочного носителя, можно вытащить исправный файл куста прошлой даты и подменить повреждённый. Третий вариант - журналы: иногда тело хайва цело, а сбой вызван лишь неприменённым хвостом LOG; утилиты офлайн-форензики умеют накатывать журнал аккуратно. Отдельный совет, который встречается в старых руководствах - копировать куст "repair" из установочного образа - в современных версиях почти бесполезен, так как тот куст соответствует чистой установке.
Профилактика сводится к трём простым практикам.
- Перед серьёзными правками реестра делать reg.exe save затронутых кустов, а не только экспорт reg-файла: reg-файл не захватывает ACL и некоторые типы данных.
- Не отключать VSS и периодически проверять, что RegBack или точки восстановления действительно создаются.
- Помнить, что чистящие утилиты, "оптимизирующие реестр", чаще создают риск повреждений, чем дают выигрыш.
SAM как историческая точка интереса атакующих и эволюция защиты
Файл SAM - классический объект интереса в истории компрометаций Windows. Локальные хеши паролей в нём защищены, но исторически этой защиты не хватало: извлечённая копия SAM рядом с SYSTEM (нужного для раскрытия слоя шифрования) позволяла офлайн перебирать хеши локальных аккаунтов. Легендарный SysKey, появившийся в эпоху Windows NT 4.0, добавлял поверх SAM дополнительный ключ шифрования, который можно было держать на дискете или вводить паролем при старте. С годами слабость самой схемы SysKey и вымогательское злоупотребление ею (блокировка машины чужим стартовым паролем) привели к тому, что Microsoft объявила SysKey устаревшим и убрала его из современных Windows, опираясь на иной стек защиты: Credential Guard на базе виртуализации изолирует секреты LSA в защищённой среде VSM, TPM привязывает ключи к оборудованию, а политики вроде запрета кэширования доменных входов сужают поверхность. Технический урок прост: сам факт компактного файла с секретами делает его мишенью, и защита смещается от "зашифровать сильнее" к "не дать вытащить файл и ключ вместе".
Почему реестр пережил чистовые патчи и форсированные перезагрузки
Бинарный формат куста знаменит тем, что выдерживает отказ питания в середине записи. Это заслуга журналирования: каждый куст снабжён файлами журнала в той же папке config, и при сбросе питания в момент обновления следующий запуск просто доигрывает или откатывает транзакцию по журналу. Атомарность гарантируется иначе, чем в базах данных - через двойную запись новых блоков и переключение карты секторов, - но цель та же: никогда не оказаться с наполовину записанной веткой. Дополнительную страховку образует унаследованный механизм RegBack - копии кустов в одноимённой папке, из которых повреждённый файл можно вернуть офлайн-правкой через среду восстановления. История злоупотреблений Environment не изменила этого фундаментального устройства.
Есть и эргономический мотив: транзакция RegistryTransaction , введённая в Vista, позволила составные установки связывать в одну транзакцию реестра и файловой системы вместе с TxF, Transactional NTFS. Практически TxF не получила распространения из-за сложности и была осторожно отведена, но идея осталась в том, как Windows Installer откатывает неудачные установки - через отдельные таблицы отката. Для оператора восстановления важнее другое: пока существует среда восстановления на отдельном разделе и пока журналы исправны, повреждённый куст не является приговором, а является файловой задачей: подключиться из WinRE, положить исправный файл из резерва и перезагрузиться.
От ini-файлов к реестру и инструменты аудита
Ранняя Windows хранила конфигурацию в текстовых ini-файлах: win.ini, system.ini, россыпи .ini рядом с каждым приложением. Подход был прозрачен, но рушился при росте: нет типов данных, нет прав доступа, нет централизации, конфликты при одновременной записи, чудовищная путаница в многопользовательской среде. Реестр в Windows NT 3.1 и затем Windows 95 стал ответом: типизированные значения, ACL на ключи, транзакционность, разделение машины и пользователя. Цена - бинарная нечитаемость и риск централизованного повреждения, который и смягчают журналы и RegBack.
Для аудита реестр атакующих любят и защитники. Ключи Run и RunOnce в HKLM и HKCU - самые известные точки автозапуска, и Autoruns от Sysinternals читает их наряду с десятками других (службы из SYSTEM, задачи, обработчики из SOFTWARE). Защитная работа с реестром выглядит так: снятие снимков reg.exe save до и после установки ПО, сравнение изменений, мониторинг записи в Run-ключи, аудит ACL на критичные ветви. За привычным regedit стоит вся описанная машинерия: открывая его, администратор на самом деле смотрит сквозь объектное пространство имён ядра в бинарные файлы на диске, чьи журналы, ACL и симлинки делают этот обзор возможным, надёжным и восстанавливаемым.