Ты, конечно же, отлично знаешь, что такое реестр и чему он служит и, наверняка, не раз пользовался regedt32.exe или regedit.exe для его изменения и настройки. Существует огромное количество разнообразных статей, книг и обзоров посвященных логике построения реестра, описывающих его настройку - нахождение тех, или иных параметров, их допустимые значения и их воздействие на работу системы. "Хакер" тоже неоднократно публиковал статьи посвященные этой теме. А вот как быть с другой стороной вопроса - что есть реестр физически, каким образом в Win2k организовано хранение реестра на диске, как система обрабатывает запросы приложений на получение информации из registry, какие существуют меры защиты сердца операционной системы?
Hive cluster#1 (устройство)
Реестр, на диске хранится не в одном, а в нескольких файлах - каждый такой файл называется ульем (hive). В ульях хранятся т.н. корневые ключи, т.е. вершины древовидных структур реестра, вроде HKEY_USERS, от которых отходят остальные разделы, ключи и их значения. Запустив regedt32.exe, ты увидишь пять корневых ключей (HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT и HKEY_USERS), можно подумать, что каждому из этих ключей соответствует отдельный файл улья. Это не совсем так. На самом деле, ни один из этих ключей не хранится на винчестере.
Соответствие файлов и имен ключей в regedt32.exe
| HKEY_LOCAL_ MACHINE\SYSTEM | \winnt\system32\config\system |
| HKEY_LOCAL_ MACHINE\SAM | \winnt\system32\config\sam |
| HKEY_LOCAL_ MACHINE\SECURITY | \winnt\system32\config\security |
| HKEY_LOCAL_ MACHINE\SOFTWARE | \winnt\system32\config\software |
| HKEY_USERS\ DEFAULT | \winnt\system32\config\default |
Все, реальными являются только эти ключи, все остальные - либо являются ссылками на их подразделы, либо создаются системой с нуля при загрузке и полностью хранятся в оперативной памяти. Например, HKEY_CLASSES_ROOT не более чем ссылка на HKEY_LOCAL_MACHINE\SOFTWARE\Classes (можешь убедиться в этом раскрыв оба этих ключа - их содержимое совпадает), HKEY_CURRENT_USER - ссылка на один из подразделов ключа HKEY_USERS, а HKEY_LOCAL_MACHINE\HARDWARE - ключ содержащий информацию об оборудовании и зарезервированных им ресурсах создается при загрузке. Определение аппаратной конфигурации и выделение ресурсов осуществляются каждый раз при старте Windows, так что отказ от хранения этой информации на жестком диске вполне логичен.
Пространство ульев делится на блоки, подобно тому, как винчестер делится на кластеры. Каждый блок имеет размер 4 килобайта (4096 байт ;). Делением ульев на блоки, добавлением их нужного количества при увеличении количества хранимой информации занимается Configuration manager (это компонент ядра Windows, который организует хранение принадлежащих реестру файлов, управляет считыванием и модификацией ключей и их значений из программ). Каждый улей имеет т.н. базовый блок, где хранится номер текущей версии улья, контрольную сумму и полное имя улья, например systemroot\config\default. Там же хранится подпись regf, по которой ОС определяет, что файл является файлом улья. Млин, в Майкрософте наверное пчеловоды работают - в ульях, данные хранятся в сотах (логично, да? :). Соты содержат в себе ключи и их значения. Структура сота состоит из нескольких полей, в них указываются: размер сота, тип данных и сами данные, как видишь, всё довольно просто. При создании нового сота, система создает т.н. рамку (bin), размер которой равен округленному вверх размеру будущего сота. Если размер рамки больше размера сота, то остаточное пространство рассматривается как свободное - туда могут быть помещены другие соты.
Hive cluster#2 (защита)
Помимо самих файлов ульев, в каталоге winnt\system32\config хранятся и их резервные копии (log hive) - файлы с расширениями .log (system.log, sam.log и т.д.) - они призваны помочь в восстановлении системы в случае повреждения реестра. Configuration Manager создаёт массив, каждый бит которого соответствует одному сектору улья (512 байт). На сленге он называется "массив грязных секторов". Если какой-то бит равен 1, это значит, что соответствующий сектор был изменен, и нужно сделать его резервную копию на винчестере.
Когда происходит модификация реестра, Configuration Manager отмечает измененные сектора в массиве, но бэкап происходит не сразу. Сначала, назначается временная задержка (hive sync), перед записью модифицируемых ключей на диск. Так, фиксируются все изменения реестра со времени поступления запроса на сохранение копий ульев и до начала осуществления этой операции. Очередная синхронизация не может производиться раньше чем через 5 секунд после предыдущей.
Если бы ОС просто сбрасывала все "грязные" сектора в файл улья, то в случае аварии этот файл оказывался бы поврежденным и не мог бы быть восстановлен. Чтобы этого не случилось, сначала массив "грязных" секторов и сами эти сектора сбрасываются в .log файл (т.н. журнальный файл) улья, размеры которого при необходимости могут быть увеличены. Затем увеличивается номер последовательности обновления в базовом блоке файла, и только после этого "грязные" сектора записываются в основной файл улья. В заключение всей работы увеличивается номер в последовательности обновления и в базовом блоке основного файла улья. Таким образом, если во время синхронизации произойдет авария, при последующей перезагрузке Configuration Manager обнаружит несовпадение номеров последовательности обновления в базовых блоках основной и резервной копий улья и завершит синхронизацию с использованием журнального файла. В результате не только дисковая копия улья окажется полностью корректна, но и никакие из
последних изменений не будут потеряны.
Для улья SYSTEM, как наиболее важного, предусмотрена еще одна, дополнительная степень защиты. В каталоге \winnt\system32\config хранятся три файла - system, system.log и system.alt. Configuration Manager хранит в файле system.alt пассивное зеркало улья SYSTEM, которое обновляется в процессе синхронизации точно так же, как его основная дисковая копия. Если в процессе загрузки обнаружится, что основная копия улья SYSTEM неисправна, Configuration Manager попытается использовать альтернативную.
Hive Cluster#3 (оптимизация)
Configuration Manager использует поддерживаемый Win2K кэш в форме хэш-таблицы Cache Table для хранения тех блоков управляющих параметров, обращаются к которым чаще всего. При обработке обращения к блоку управляющих параметров Configuration Manager первым делом проводит поиск в Cache Table.
И наконец, еще один кэш Delayed Close Table используется для хранения недавно закрытых приложениями блоков управляющих параметров. Configuration Manager обычно освобождает такие блоки, но в Win2K они сохраняются в Delayed Close Table на случай, если приложение попытается повторно открыть недавно закрытый блок. Если свободных мест нет, для добавления очередного закрытого блока сначала удаляется блок, находящийся в таблице дольше всех.
EOF
Это, конечно же не все - на эту тему, можно ещё долго говорить и говорить (типа, мой конек 8-). Юзай поисковики - найдешь тонны полезной инфы!
