Восстановление реестра - Пример работы с RegChecker-ом

В очередной раз мне в руки попал покореженный реестр и я решил законспектировать свои действия и дать некоторые пояснения по работе РегЧекера. В первую очередь следует сохранить копию файла реестра. Дальше можно делать с ним все что угодно, например стереть и никогда не вспоминать. Но я предлагаю попытаться восстановить по возможности большую часть данных из него. Для этого запустим проверку файла с помощью Registry Checker.

Вначале проверяются заголовок файла (секция [header]) и связи между сегментами данных (секция [subheaders]). На этом этапе делается предположение о том, является ли файл файлом реестра, и исправляются ВОЗМОЖНЫЕ НЕТОЧНОСТИ. После этого производится анализ блоков данных внутри сегментов. Если найденные ошибки не исправлены, то проверка прекращается. Итак, перейдем к проверке конкретного файла:

  Registry Checker 0.5 for WinNT/2K/XP by General Paul Lee (c) 2003-2004.
  =[header]====================================================================== 
  Warning. Fields Seq1 and Seq2 not equal 1. Update?[Y/N]:y
  Warning. Timestamp in header must be null. Update?[Y/N]:y
  =[subheaders]==================================================================
  00001000 Warning. Fields Size and Size-reserved not equal. Update?[Y/N/A]:a
  Warning: several fields is not 0. Clean?[Y/N/A]:a
  00381000 total subheaders: 327
  =[datablocks]==================================================================
  00084040 *** wrong size of block; patch this?[Y/N/A]:a
  =[links]=======================================================================
  00001020  Error: root key can't have a link to parent key. Correct?[Y/N]:y
  00083FE0  Error: pointer to child index is wrong. Clean?[Y/N]:y
  Error. Pointer to parameter index is wrong. Clean?[Y/N]:y
  000CEA80 Error. Pointer to parameter index is wrong. Clean?[Y/N]:y
  Error. Parameter count must be 0. Update?[Y/N]:y
  0027FA28 Error. Pointer to parameter index is wrong. Clean?[Y/N]:y
  Error. Parameter count must be 0. Update?[Y/N]:y
  Total errors in "links" section: 11
  *** following blocks can be restored
  00001000 sk cnt:00000001h MaxLen:00001000h
  000840E8 nk cnt:00000000h MaxLen:00000460h ind1:0020F438h
  See ChkNtLnk.log
  See ChkNtBlk.log
  See ChkNtHdr.log

При проверке целостности блоков данных (секция [datablocks]) найдена ошибка по адресу 84040h: предыдущий блок по адресу 83FE0h имеет размер 60h, но за ним не начинается новый блок. Чекер пытается найти следующий правильный блок данных (по адресу 84200h) и помечает поврежденный блок свободным, указывая правильный размер. Кроме того, тело блока заполняется значением dword 4 на случай возможной ссылки внутрь поврежденного блока - таким образом ссылка приведет на свободный блок размером в 4 байта. Сбойный участок локализован.

Далее, при анализе ссылок в блоках данных (секция [links]), обнаруживается ошибка в блоке, примыкающем сверху к сбойному участку (адрес 83FE0h). В дампе хорошо видно, что большая часть этого блока затерта. Что можно сделать с этим блоком?
Во-первых найти родителя и узнать полный путь до ключа; плюс к этому, можно узнать часть наименования ключа, если в качестве индекса использовался lf-блок; если ключ стандартно присутствующий в системе, то можно предположить его название, анализируя ключи из другого/сохраненного реестра.
Во-вторых, следует поискать ссылки на этот блок, как на родителя (в данном случае таких нет - они появляются в логах). С параметрами сложнее - блоки параметров не имеют ссылок на родителя, к тому же они не имеют сигнатур, что затрудняет их обработку.

Визуально видно, что имеет место быть ошибка записи данных размером 512 байт начиная с адреса 84000h. Природа возникновения ошибки не мне известна.

В файле лога все найденные ошибки расписаны более подробно. Видно, что почти все они связаны именно со сбойным участком.

 NTUSER.DAT
 =[links]=======================================================================
 --------------
  Address  Type
 --------- ----
 00001020:  nk root key can't have a link to parent key. Updated.
 00016F78:  nk (00084140: 00000004)-> [B] ^parameter is wrong
 00083CC0:  nk (00084188: 00000004)-> [1] ^parameter is wrong
 00083FE0:  nk out of range (00001000) ^childIndex is wrong
 00083FE0:  nk pointer to child index is wrong. Updated.
 00083FE0:  nk out of range (00001000) ^security is wrong
 00083FE0:  nk out of range (00001000) ^class is wrong
 00083FE0:  nk out of range (00001000) ^parIndex is wrong
  Updated.
 00088CF0:  nk (000841D0: 00000004)-> [2] ^parameter is wrong
 000A6960:  nk (000841B0: 00000004)-> [1] ^parameter is wrong
 000CEA80:  nk (00084168: 00000004) ^parIndex is wrong
  Updated.
  Updated.
 0020F438:  lf (000840E8: 00000004) ^child is wrong
 0027FA28:  nk (00084178: 00000004) ^parIndex is wrong
  Updated.
  Updated.
 *** following blocks can be restored
 00001000 sk cnt:00000001h MaxLen:00001000h
 000840E8 nk cnt:00000000h MaxLen:00000460h ind1:0020F438h

Что из этого следует? По адресу 16F78h находится блок ключа (nk) с кучей параметров. Один из них (11-й по счету) находился когда-то по адресу 84140h, но теперь его там нет и по этому адресу записано значение dword 4.

Что делать в этом случае? Находим этот ключ, в нем адрес индекса по параметрам (не забываем прибавить 1000h), находим сам индекс и в нем 11-й адрес - он уже не нужен, поэтому все данные за ним до конца индекса сдвигаем на 4 байта вверх, тем самым затирая бесполезный для нас адрес (размер блока остается неизменным); да, в самом блоке ключа еще следует уменьшить счетчик количества параметров.

Следующая строка лога - аналогично. Кстати, если все параметры потеряны, то можно пометить блок индекса свободным (указав положительный размер), счетчик параметров в ключе обнулить, а указатель на индекс по параметрам сделать равным -1.

Далее куча ошибок в приграничном блоке - их так много, а значимости в ключе так мало, что правильным решением было бы избавиться от этого блока (только в данном случае, так как нет потомков). Если оставлять ключ в живых, то надо привести в порядок все указатели (указатель на индекс по потомкам уже исправлен), записав в них значение -1; найти родителя, из него индекс по потомкам и прикинуть возможное название ключа (в данном случае первые 4 символа "Mult") и путь до него (в данном случае "Software\Creative Tech"); далее, глядя в описание структуры реестра, прописываем ключу подходящее имя; поскольку адрес ключа защиты неизвестен, то прописываем адрес из родителя, не забывая увеличить счетчик в ключе защиты.

Еще одна строка лога - для ключа с адресом 0CEA80h пропал индекс по параметрам (был когдато здесь - 84168h), он уже исправлен.

Далее - оказывается, по адресу 840E8h когда-то был блок ключа... какая досада, все что от него осталось - лишь ссылка в в индексе по потомкам, странное имя "6" и полный путь "Software\Microsoft\Windows\CurrentVersion0\Explorer\Streams"; детей у покойного не было...

В этом случае есть два варианта - либо восстановить останки, либо окончательно их закопать. О первом я только что написал, а второе напоминает удаление адреса из индекса по параметрам, за тем исключением, что сдвиг призводится на 8 байт, а счетчик количества потомков меняется в двух местах - в блоке ключа и непосредственно в индексе по потомкам.



Вот такой сумбур. Данный конкретный случай является примером пожалуй 90% всех поломок реестра, которые мне случалось видеть, разница лашь в количестве "проплешин" и пагубности последствий - здесь, можно сказать, вообще ничего не случилось.