Статический анализ стратегии

Дисковый монитор Марка Руссиновичка (http://www.sysinternals.com) позволяет заглянуть в "святая святых" файловой системы и увидеть как именно она выделят дисковое пространство для файлов. Особенно интересно запускать его параллельно с дефрагментатором и chkdsk'ом – тайное сразу становится явным.

хранение имен файлов и директорий

Структура direct определена в файле /src/ufs/ufs/dir.h и содержит: номер inode, описывающий данный файл, тип файла, его имя, а так же длину самой структуры direct, используемую для нахождения следующего direct'а в блоке.

struct direct {

/* 0x00 */ u_int32_t d_ino; /* inode number of entry */

/* 0x04 */ u_int16_t d_reclen; /* length of this record */

/* 0x06 */ u_int8_t d_type; /* file type, see below */

/* 0x07 */ u_int8_t d_namlen; /* length of string in d_name */

/* 0x08 */ char d_name[MAXNAMLEN + 1];/* name with length <= MAXNAMLEN */

};

восстановленная структура директорий

Хваленный Easy Recovery от Data Recovery Software вопреки своему названию простотой управления отнюдь не отличается и имеет довольно специфические особенности поведения. С настройками по умолчанию никаких файлов на отформатированном разделе он не увидит и чтобы заставить этого зверюгу заработать в Advanced Options (дополнительные опции) необходимо указать Ignore MFT (игнорировать MFT), но и в этом случае качество восстановления будет оставлять желать лучшего.

Disk Probe отображает Partition Table

Acronis DiskEditor – слегка улучшенный клон Disk Probe. Разукрашен интерфейс, существенно упрощена процедура выбора дисков, по PageDown/PageUp переходит к следующему/предыдущему сектору. В поиске появилась поддержка большого количества различных кодировок (DiskProbe понимает только Cyrillic Windows-1251), и HEX-поиск. Но есть и упущения. При масштабировании окна меняется и количество байт в строке, что делает навигацию по сектору весьма противоречивой и затруднительной, к тому же текущая позиция курсора отображается только в десятичном виде (у DiskProbe – в шестнадцатеричном), что так же не добавляет восторга.

описание порядка размещения файла на диске, иерархия непосредственных и косвенных блоков

Имя файла в inode не хранится. Ищите его внутри директорией, представляющих собой массив записей следующего вида:

смещение размер описание

------- ------- -----------

0 4 inode ; ссылка на inod'у

4 2 rec_len ; длина данной записи

6 1 name_len ; длина имени файла

7 1 file_type ; тип

файла

8 ... name ; имя файла

Acronis DiskEditor отображает NTFS boot-сектор

DiskExplorer от Runtime Software – великолепный дисковый редактор, самый лучший из всех с которыми мне только доводилось работать. Фактически это клон Norton DiskEditor под Windows NT/9x с полной поддержкой NTFS. Вы можете просматривать все основные NTFS-структуры в естественном виде, монтировать виртуальные диски, работать с образами лазерных и жестких дисков, перемещаться по директориям, восстанавливать удаленные файлы из любой записи MFT, копировать файлы (и даже целые директории!) с предварительным предпросмотром в текстовом или шестнадцатеричном формате и это еще далеко не все! Удобная система forward/backward навигации (приблизительно такая же как в браузере или IDA PRO, даже гиперссылки поддерживаются), изобилие горячих клавиш, история переходов, мощный поиск с поддержкой основных структур (INDEX, MFT, Partition), поиск ссылок на текущий сектор, возможность удаленного восстановления диска с подключением по TCP/IP, локальной сети или прямому кабельному подсоединению. Все числа выводятся в двух системах исчисления – шестнадцатеричной и десятичной.

Короче говоря, это мой основной (и при том горячо любимый!) инструмент для исследования файловой системы и восстановления данных. Первое же знакомство с ним вызывает эйфорию, граничащую со щенячьим восторгом. Наконец-то мы получили то, о чем так долго мечтали. Естественно, за все хорошее надо платить. Disk Explorer это коммерческий продукт, а доступная для скачивания демонстрационная версия лишена возможности записи на диск. Причем, имеются две различные версии редактора: одна поддерживает NTFS (http://www.runtime.org/gdbnt.zip), другая – FAT. Так же доступны плагины под Bart's PE, которые можно скачать с сайта Runtime Software.

DiskExplorer отображает MFT в расширенном виде

Sector Inspector, входящий в бесплатно распространяемый фирмой Microsoft пакет "Windows Resource Kits", представляет собой не интерактивный утилиту для чтения/записи отдельных секторов в файл. Поддерживает LBA и CHS адресацию. При запуске без параметров выводит декодированную partition table вместе с расширенными разделами и boot-секторами. Редактирование диска осуществляется правкой секторного дампа в любом подходящем HEX-редакторе с последующей записью исправленной версии на диск. Естественно, это непроизводительно и неудобно, однако, Sector Inspector единственный известный мне редактор, поддерживающий работу из Recovery Console, так что в некоторых случаях он бывает просто незаменим!

внешний вид GetDataBack

DIY Recover от нидерландской фирмы с неоригинальным названием Data Recovery – замечательный полуавтоматический доктор с кучей настроек. Поддерживает динамические диски, позволяет задавать все параметры сканирования вручную. Надежен. Не зависает даже на сильно поврежденных томах. Правда, навигация по восстанавливаемому диску выполнена крайне неудобно (если не сказать – небрежно), что особенно хорошо заметно на больших дисках, содержащих миллионы файлов. Как и его соперник – GetDataBack – он ничего не лечит, а лишь вытягивает уцелевшие данные из небытия. Тем не менее, я отношу DIY Recover к лучшим автоматизированным средствам восстановления из всех имеющихся в моем арсенале (не считая своих собственных утилит, которые пишутся на скорую руку для восстановления конкретного диска, после чего уходят в /dev/null, как и всякий фаст фуд). Демонстрационную копию программы можно найти по следующему адресу http://www.diydatarecovery.nl/~tkuurstra/downloads/Demo/iRecoverSetup.exe.

ползущая змейка DIY Recover'a

Easy Recovery Professional от OnTrack Data Recovery (www.ontrack.com) – симпатичный, но на проверку довольно бестолковый инструмент, к тому же работающий полностью в автоматическом режиме, интеллектуальность которого находится на зачаточном уровне. Не рекомендуется для использования (ну разве что вы хотите восстановить только что отформатированный том на который еще ничего существенного не писалось).

расширенная таблица разделов

Штатные утилиты разбивки (FDISK.EXE, Disk Manager) в каждой таблице разделов создает один основной и один расширенный раздел. Т. е. если при разбиении винчестера на четыре логических диска, на нем образуется четыре partition table (см. листинг 4), хотя в данном случае можно было бы обойтись и одной. Штатный загрузчик FDISK'а требует, чтобы активный раздел находится в первом секторе partition table, "благодаря" чем операционная система может грузиться только с диска C:. Нестандартные менеджеры, анализирующие всю цепочку разделов, позволяют загружаться с любого из разделов. Самые честные из них создают в первой partition table еще один раздел (благо если диск был разбит FDISK'ом свободное место там всегда есть), назначают его активным и помещают в него свое тело. Другие же внедряются непосредственно в MBR, замещая первичный загрузчик, что создает очевидные проблемы совместимости.

Если таблица разделов повреждена, логические диски скорее всего будут полностью недоступны – они отсутствуют в "Моем Компьютере", не появился в панели "Driver" файлового менеджера FAR'а, а команда C: вызывает ошибку. Искажение таблицы разделов не приводит к немедленному изменению объема уже отформатированных томов (т. к. он храниться в boot-секторе и картах свободного пространства), но при последующим переформатировании произойдет затирание данных из соседнего раздела, или же текущий раздел окажется усечен. Кстати говоря, если расширенный раздел указывает сам на себя или на один из предшествующих разделов в цепочке, все известные мне операционные системы наглухо зависнут еще на этапе загрузки, даже если диск подключен "вторым". Чтобы исправить ситуацию, необходимо запустить редактор диска или другую утилиту, а для этого необходимо загрузить операционную систему! Существует несколько путей выхода из этой, казалось бы неразрешимой проблемы. Самое простое – горячее подключение диска на ходу с последующей работой с ним через BIOS или порты ввода/вывода. Если ни диск, ни материнская плата не умет (а для IDE-устройств подключение "на лету" представляется довольно жестким испытанием!), вы сможете запустить доктора и работать с диском на физическом уровне. Другой, чисто хакерский, путь – пропатчить MS-DOS, изменив сигнатуру 55h AAh на что-нибудь еще, тогда она не сможет распознать таблицу разделом и стало быть, не станет ее анализировать. Как вариант можно записать в boot-сектор дискеты специально подготовленную программу, которая обнуляет MBR или искажает сигнатуру, расположенную в его конце. Просто загрузитесь с нее и все!

смещение	размер	назначение
0x000	перемен.	код загрузчика
1x1BB	4h	идентификатор диска
0x1BE	10h	Partition 1
0x1CE	10h	Partition 2
0x1DE	10h	Partition 3
0x1EE	10h	Partition 4
0x1FE	0x2	признак таблицы разделов сигнатура 55h Aah

LMD-база и ее дислокация

Внутреннее устройство LDM-база недокументированно и буквально пышет мощью и сложностью. Наверху иерархии расположено оглавление базы – структура TOCBLOCK (Table Of Content Block), состоящая из двух секций config и log (вероятно, в будущем их список будет расширен). Секция config содержит информацию о текущем разбиении динамических дисках и сведения о томах, а log хранит журнал изменений схемы разбивки. Это очень мощное средство в борьбе с энтропией! Если удалить один или несколько динамических разделов, информация о старом разбиении сохранится в журнале и утерянные тома могут быть с легкостью восстановлены! Будучи очень важной структурой, оглавление диска защищено от случайного разрушения тремя копиями, одна из которых вплотную примыкает к настоящему TOCBLOCK'у, расположенному в начале LDM-базы, а две других находится в конце диска, между копиями PRIVHEAD.

Внутренне секция config состоит из заголовка (VMDB) и одного или нескольких VBLKs – специальных 128-байтовых структур данных, каждая из которых описывает соответствующий ей том, контейнер, раздел, диск или группу дисков. VMDB-заголовок не имеет копии и нигде не дублируется, однако все его изменения протоколируется в журнале (KLOG) и потому могут быть восстановлены.

Строение VMDB и VBLs подробно документировано "LMD Documentation", находящейся на сайте LINUX-NTFS и потому описывать его здесь нет никакой необходимости (оно слишком громоздко, к тому же крайне маловероятно, что кому-то потребуется восстанавливать секцию config руками).

внутри LDM

Для просмотра LDM-базы и архивирования ее содержимого можно воспользоваться утилитой LDM-dump Марка Руссиновича, бесплатную копию которой можно скачать с его сайта (http://www.sysinternals.com/files/ldmdump.zip). Как вариант – можно зарезервировать последний мегабайт физического диска и последний мегабайт всех патриций чей Boot ID равен 42h любым подходящим дисковым редактором (например, Sector Inspector'ом) и сохранить эту информацию на надежном носителе (Zip'е, СD-R/RW), не забывая так же зарезервировать и TOCBLOCK.

При восстановлении удаленных динамических дисков следует учитывать, что: во-первых, журнал изменений на интерфейсном уровне недоступен и выполнить откат легальными средствами операционной системы невозможно. Во-вторых, boot-сектор удаляемых дисков автоматически очищается и восстанавливать его приходится вручную, о чем мы чуть позже и поговорим.

Если размер и тип удаленного динамического диска вам известен (на NTFS-дисках его можно извлечь из копии boot-сектора), просто зайдите в Менеджер Управления Дисками и воссоздайте его заново, от предложения отформатировать раздел любезно откажитесь и восстановите очищенный boot-сектор по методике, описанной ниже.

Как видно, Microsoft тщательно позаботилась о своих пользователях и занималась проектированием структуры динамических дисков на свежую голову, что для нее вообще говоря нехарактерно.

базовые (Basic) разделы		динамические (Dynamic) разделы
основный раздел/Primary partition		простой том/Simple volume
системный и загрузочный раздел/System and boot partitions		системный и загрузочный том/System and boot volumes
активный раздел/Active partition		активный том/ Active volume
расширенный раздел/Extended partition		том и свободное пространство/Volume and unallocated space
логический диск/Logical drive		простой том/Simple volume
набор томов/Volume set		составной том/ Spanned volume
чередующийся набор/ Stripe set		чередующийся том/ Stripe set

Ручное восстановление файла по FILERecord

Начнем с простейшего. Файл только что удален и принадлежащая ему FILE Record еще не затерта. Как найти его на диске? Существует два способа – "теоретический" и "практический". Теоретический исключительно надежен, но требует дополнительных телодвижений, которых можно избежать, приняв ряд практических допущений.

Теоретически: извлекаем из boot-сектора указатель на MFT, извлекаем из нее первую запись (она описывает $MFT), находим атрибут $DATA (80h), декодируем список отрезков (data runs) и последовательно читаем все записи в MFT, анализируя содержимое атрибута $FILE_NAME (30h) – имя файла (кстати, таких атрибутов у файла может быть несколько). Этот же атрибут хранит ссылку на материнскую директорию – если несколько одноименных файлов удалены из различных директорий, мы должны разобраться какой из них наш.

Практически: в девяти из десяти случаев $MFT файл не фрагментирован и располагается практически в самом начале диска. Имена файлов хранятся по смещению EAh от начала сектора, в начале которого расположена сигнатура "FILE*" ("FILE0" – в NTFS 3.1). Поэтому, мы просто запускаем любой дисковый редактор (например, Disk Probe из комплекта Support Tools от Microsoft), вводим имя восстанавливаемого файла в уникоде и говорим искать его по смещению EAh (в NTFS 3.1 – F0h) от начала сектора.

Когда же искомое вхождение будет найдено, смотрим: находится ли в начале сектора сигнатура "FILE*"/"FILE0" и если нет – продолжаем поиск. Двухбайтовое поле по смещению 16h от начала сектора содержит флаги записи: 00h – запись не используется или была удалена, 01h – запись используется и описывает каталог, 02h – запись используется и описывает директорию. Встречаются и другие значения (04h, 08h… что они обозначают – неизвестно. может быть, вы, читатель, сможете пролить свет на этот вопрос?).

Ручное восстановление отформатированного диска

Нашей целью будет ручное восстановление всего отформатированного раздела без использования дополнительных носителей информации и дорогостоящих утилит от сторонних производителей. Все что потребуется— это любой редактор диска (предпочтительнее всего конечно же NT Explorer от Runtime Software, но на худой конец сойдет и бесплатный Disk Probe/Sector Inspector от Microsoft) и chkdsk.

Очевидно, что в процессе форматирования происходит необратимое разрушение большого количества ключевых структур данных, восстанавливать которые вручную было бы слишком затруднительно. Да это, собственно, и не нужно! Идея состоит в том, чтобы вернуть разделу потерянные файловые записи, а все остальные ремонтные работы поручить chkdsk'у — пускай старается.

Дизассемблирование показывает, что единственной структурой данных, без которой не может работать chkdsk, является атрибут $DATA файла $MFT. А раз так, все, что нам надо —воссоздать прежний $MFT:$DATA, разместив его поверх старых файловых записей. В простейшем случае (если $MFT:$DATA не фрагментирован) это достигается спекулятивным увеличением его длины. А как ее увеличить?

Запускаем NT Explorer, переходим в начало MFT (Goto à Mft), щелкаем по $MFT файлу, находим атрибут $DATA (80h) и увеличиваем поля Allocated Size/Real Size/Compressed Size на требуемую величину, параллельно с этим корректируя список отрезков (он же run-list). Поле Last VCN трогать не нужно — chkdsk исправит его и сам. Как определить длину не фрагментированного MFT-файла? Она равна разнице номеров первого и последнего секторов в начале которых присутствует сигнатура "FILE", умноженная на 512 байт (исключая сектора, принадлежащие $MFTMirr) Известные мне дисковые редакторы не поддерживают поиска последнего вхождения, поэтому соответствующую утилиту приходится писать самостоятельно. Впрочем, точную длину MFT определять совершенно необязательно и вполне допустимо взять ее с запасом — лишнее все равно отсеет chkdsk. Действуйте по принципу — лучше перебрать, чем недобрать.

Списки отрезков (data runs)

Тела нерезидентных атрибутов хранятся на диске в одной или нескольких кластерных цепочках, называемых отрезками

(runs). Отрезком называется последовательность смежных кластеров, характеризующаяся номером начального кластера и длинной. Совокупность отрезков называется списком, run-list'ом или data run'ом.

Внутренний формат представления списков не то, чтобы сложен, но явно не прост, за что получил прозвище brain damage format'а (формата, срывающего крышу и обламывающего кайф). Для экономии места длина отрезка и номер начального кластера хранятся в полях переменной длины. То есть, если размер отрезка умещается в байт (т.е. его значение не прерывает 255), он и хранится в байте. Соответственно, если размер отрезка требует для своего представления двойного слова, он и хранится в двойном слове.

Сами же поля размеров хранятся в 4-байтовых ячейках, называемых нибблами (nibble) или полубайтами. Шестнадцатеричная система исчисления позволяет легко переводить байты в нибблы и наоборот. Младший ниббл равен (X & 15), а старший – (X / 16). Легко видеть, что младший ниббл соответствует младшему шестнадцатеричному разряду байта, а старший – старшему. Например, 69h состоит из двух нибблов – младший равен 9h, а старший – 6h.

Список отрезков представляет собой массив структур, каждая из которых описывает характеристики "своего" отрезка, а в конце списка находится завершающий нуль. Первый байт структуры состоит из двух полубайт: младший задает длину поля начального кластера отрезка (условно обозначаемого буквой F), старший – количество кластеров в отрезке (L). Поле длины отрезка идет следом. В зависимости от значения L оно может занимать от одного до восьми байт (более длинные поля недопустимы). Первый байт поля стартового кластера файла расположен по смещению 1 + L байт от начала структуры (что соответствует 2+2*L нибблам). Кстати говоря, в документации Linux-NTFS Project (версия 0.4) поля размеров начального кластера и количества кластеров в отрезке перепутаны местами.

смещение в нибблах	размер в нибблах	описание
0	1	размер поля длины (L)
1	1	размер поля начального кластера (S)
2	2*L	количество кластеров в отрезке
2+2*L	2*S	номер начального кластера отрезка

Структура диска – базовые концепции

Физически жесткий диск представляет собой запечатанную банку с одной или несколькими одно или двухсторонними пластинами, насажанными на шпиндель. Чтение/запись данных осуществляется блоком магнитных головок, каждая их которых обслуживает одну из поверхностей пластины. Информация хранится в форме концентрических колец, называемых треками

(track) или дорожками. Треки, расположенные на равном расстоянии от центра всех пластин, образуют цилиндр

(cylinder). Фрагмент трека, образованный радиальным делением, называется сектором (sector). В современных винчестерах количество секторов на трек не остается постоянным и дискретно растет по мере удаления от центра пластины, поддерживая более или менее постоянные линейные размеры сектора. Треки и головки нумеруются начиная с нуля, сектора – начиная с единицы. Размер сектора для жестких дисков – 512 байт.

Первой схемой адресации секторов, доставшейся жестким дискам в наследство от дискет, стала так называемая CHS-адресация, представляющая собой сокращение от Cylinder/Head/Sector (Цилиндр/Головка/Сектор) и возникшая под давлением экономических причин. Когда-то, координаты адресуемого сектора напрямую соответствовали физической действительности, что упрощало (а, значит, и удешевляло!) дисковый контроллер, не требуя от него никакой интеллектуальности. Помимо того, что такая схема адресации чудовищна неудобна для программистов (последовательное чтение диска растягивается на три вложенных цикла!), она еще и до неприличия косна! Количество секторов в треке должно быть постоянным для всего диска, а в новых винчестерах это не так. Поэтому, для сохранения совместимости с существующим программным обеспечением, дисковый контроллер виртуализует геометрию винчестера, что ставит нас в зависимость от выбранной схемы трансляции (а схема трансляции – дело сугубо внутреннее и потому не стандартизированное). Параметры диска, сообщаемые устройством и напечатанные на этикетке, всегда

виртуальные и никакой возможности узнать реальное положение дел у нас нет.

IDE- диски благодаря наличию интегрированного контроллером внутри, в наименьшей степени зависимы от внешнего мира и могут свободно мигрировать от одной машины к другой (при условии корректного поведения BIOS'а, но об этом чуть позже). Некоторые винчестеры поддерживают специальную ATA-команду "Initialize device parameters", устанавливающую текущую виртуальную геометрию диска, а точнее выбранное количество головок и число секторов на дорожку. Количество цилиндров вычисляется контроллером самостоятельно, на основании общего объема диска, который кстати говоря, также можно изменять программными средствами (за это отвечает ATA-команда SET MAX ADDRESS). Некоторые драйвера (и BIOS'ы) изменяют геометрию диска, привязывая винчестер к себе прочными брачными узами и в другом окружении такой диск работать уже не будет, ну во всяком случае до установки правильной геометрии.

Со SCSI-устройствами ситуация обстоит гораздо хуже и диск соглашается работать только с тем контроллером, под которым он был отформатирован. Различные контроллеры используют различные схемы трансляции и потому подключение диска к несовместимому контроллеру произвольным образом "перемешивает" сектора. Редактор диска с таким винчестером работать еще будет, а вот штатные средства операционной системы (и большинство "докторов") нет.

Продвинутые контроллеры автоматически замещают плохие сектора, либо сохраняя эту информацию в свой энергонезависимой памяти, либо в записывая ее в инженерные сектора самого диска. Это еще сильнее привязывает накопитель к его контроллеру (правда, некоторые SCSI-диски выполняют переназначение секторов собственными средствами). Таким образом, выход SCSI-контроллера из строя фактически приравнивается к отказу самого диска. Никогда не приобретайте SCSI-контроллеры no-name производителей – в любой момент они могут кануть в лету и тогда поставки новых контроллеров прекратятся. Контроллеры, интегрированные в материнские платы, это вообще песня. Ненадежные, ни с чем не совместимые… а что вы еще хотели за такую цену?

Сложнее всего приходится RAID-массивам, схема трансляции адресов которых полностью определяется контроллером. Массивы уровня 1 (mirroring или зеркала) чаще всего транслируются всквозную и без особых проблем могут быть перенесены на любой другой контроллер или даже подключены в обход него. Массивы остальных уровней (и в особенностей RAID 3/RAID 5) на других типах контроллеров по обыкновению неработоспособны. Программные RAID'ы, монтируемые Windows NT, содержат информацию о своей геометрии в системном реестре и не могут быть непосредственно перенесены на другие системы. Переустановка Windows NT (равно как и крах оной) уничтожает программный RAID. К счастью, эта потеря обратима и в следующих статьях этого цикла мы раскроем секреты техники восстановления.

Несмотря на то, что CHS-трансляция в настоящее время признана устаревшей (устройства, придерживающиеся спецификации ATA/ATAPI-6, принятой в июне 2001 года, уже не обязаны ее поддерживать), она до сих пор встречается во многих служебных структурах операционной системы (в частности в таблице разделов и загрузочном секторе), поэтому имеет смысл остановиться на этом вопросе поподробнее, тем более, что здесь есть о чем поговорить.

На интерфейсном уровне, адрес сектора передается следующим образом (см. листинг 1)

порт                       значение

0172/01F2            кол-во секторов

0173/01F3            номер сектора (биты 0-7)

0174/01F4            номер цилиндра (биты 0-7)

0175/01F5            номер цилиндра (биты 8-15)

0176/01F6            номер головки (биты 0-3), привод на шине (бит 4), режим CHS/LBA (бит 6)

Структура файловой системы

В начале диске расположен boot-сектор (на незагрузочных разделах он может быть пустым). За ним, по смещению 1024байта от начала первого сектора лежит супер-блок (super-block), содержащий ключевую информацию о структуре файловой системе. (В FAT и NTFS эта информация хранится непосредственно в boot). В первую очередь нас будет интересовать 32-разрядное поле s_log_block_size, расположенное по смещению 18h байт от начала супер-блока. Здесь храниться размер одного блока (block) или, в терминологии MS-DOS/Windows, кластера, выраженный в виде показателя позиции, на которую нужно сдвинуть число 200h. В естественных единицах это будет звучать так: block_size = 200h << s_log_block_size (байт). То есть, если s_log_block_size

равен нулю, размер одного блока составляет 400h байт или два стандартных сектора.

смещение размер описание

------- ------- -----------

0 1 boot record ; загрузочный сектор

-- block group 0 -- ; группа блоков 0

(1024 bytes) 1 superblock ; суперблок

2 1 group descriptors ; дескриптор

группы

3 1 block bitmap ; карта свободных блоков

4 1 inode bitmap ; карта свободных inode

5 214 inode table ; массив inode (сведения о файлах)

219 7974 data blocks ; блоки данных (файлы, директории)

-- block group 1 -- ; группа блоков 1

8193 1 superblock backup ; копия

суперблока

8194 1 group descriptors backup ; копия

дескрпиора группы

8195 1 block bitmap ; карта свободных блоков

8196 1 inode bitmap ; карта свободных inode

8197 214 inode table ; массив inode (сведения о файлах)

8408 7974 data blocks ; блоки данных (файлы, директории)

-- block group 2 -- ; группа блоков 2

16385 1 block bitmap ; карта свободных блоков

16386 1 inode bitmap ; карта свободных inode

16387 214 inode table ; массив inode (сведения о файлах)

16601 3879 data blocks ; блоки данных (файлы, директории)

Структура UFS

Внешне UFS очень похожа на ext2fs– те же inod'ы, блоки данных, файлы, директории… Но есть и отличия. В ext2fs имеется только одна группа inod'ов и только одна группа блоков данных для всего раздела. UFS же делит раздел на несколько зон одинакового размера, называемых группами цилиндров. Каждая зона имеет свою группу inod'ов и свою группу блоков данных, независимую ото всех остальных зон. Другим словами, inod'е описывают блоки данных той и только той зоны, к которой они принадлежат. Это увеличивает быстродействие файловой системы (головка жесткого диска совершает более короткие перемещения) и упрощает процедуру восстановления при значительном разрушении данных, поскольку, как показывает практика, обычно гибнет только первая группа inod'e. Чтобы погибли все группы… ну я даже не знаю что же такого с жестким диском нужно сделать. А! Знаю! Под пресс положить!

В UFS каждый блок разбит на несколько фрагментов фиксированного размера, предотвращающих потерю свободного пространства в хвостах файлов. Благодаря этому, использование блоков большого размера уже не кажется расточительной идей, напротив, это увеличивает производительность и уменьшает фрагментацию. Если файл использует более одного фрагмента в двух несмежных блоках, он автоматически перемещается на новое место, в наименее фрагментированный регион свободного пространства. Поэтому, фрагментация в UFS очень мала или же совсем отсутствует, что существенно облегчает восстановление удаленных файлов и разрушенных данных.

структура резидентного атрибута

смещение	размер	значение	описание
00h	4		тип (type) атрибута (например,. 0x20, 0x80)
04h	4		длина атрибута, включая этот заголовок
08h	1	01h	нерезидентный флаг (non-resident flag)
09h	1	N	длина имени атрибута (ноль если атрибут безымянный)
0Ah	2	40h	смещение имени (ноль если атрибут безымянный)
0Ch	2		флаги
значение	описание
0001h	сжатый атрибут (compressed)
4000h	зашифрованный атрибут (encrypted)
8000h	разряженный атрибут (sparse)
0Eh	2		идентификатор атрибута (attribute ID)
10h	8		начальный виртуальный кластер (starting VCN)
18h	8		конечный виртуальный кластер (last VCN)
20h	2	2N+40h	смещение списка отрезков (data runs)
22h	2		размер блока сжатия (compression unit size), округленный до 4 байт вверх
24h	4	00h	для выравнивания
28h	8		выделенный размер (allocated size), округленный до размера кластера
30h	8		реальный размер (real size)
38h	8		инициализированный размер потока (initialized data size of the stream)
40h	2N	UNICODE	имя атрибута если есть
2N+40h	..		список отрезков (data runs)

Таблица 12 структура одного элемента списка отрезков

Покажем, как с этим работать на практике. Допустим, мы имеем следующий run-list, соответствующий нормальному не фрагментированному файлу (что может быть проще!): "21 18 34 56 00". Попробуем его декодировать?

Начнем с первого байта – 21h. Младший полубайт (01h) описывает размер поля длины отрезка, старший (02h) – размер поля начального кластера. Следующие несколько байт представляют поле длины отрезка, размер которого в данном случае равен одному байту – 18h. Два других байта (34h 56h) задают номер начального кластера отрезка. Нулевой байт на конце сигнализирует о том, что это последний отрезок в файле. Итак, наш файл состоит из одного-единственного отрезка, начинающегося с кластера 5634h и заканчивающегося кластером 5634h+ 18h == 564Ch.

Рассмотрим более сложный пример фрагментированного файла со следующим списком отрезков: "31 38 73 25 34 32 14 01 E5 11 02 31 42 AA 00 03 00". Извлекаем первый байт – 31h. Один байт приходится на поле длины и три байта на поле начального кластера. Таким образом, первый отрезок (run 1) начинается с кластера 342573h и продолжается вплоть до кластера 342573h + 38 == 3425ABh. Чтобы найти смещение следующего отрезка в списке мы складываем размер обоих полей с их начальным смещением: 3 + 1 == 4. Отсчитываем четыре байта от начла run-list'а и переходим к декодированию следующего отрезка: 32h – два байта на поле длины отрезка (равное в данном случае 0114h) и три байта на поле номера начального кластера (0211E5h). Следовательно, второй отрезок (run 2) начинается с кластера 0211E5h и продолжается вплоть до кластера 0211E5h + 114h == 212F9h. Третий отрезок (run 3): 31h – один байт на поле длины и три байта на поле начального кластера, равные 42h и 0300AAh соответственно. Поэтому, третий отрезок (run 3) начинается с кластера 0300AAh и продолжается вплоть до кластера 0300AAh + 42h == 300ECh. Завершающий нуль на конце run-list'а сигнализирует о том, что это последний отрезок в файле.

Таким образом, подопытный файл состоит из трех отрезков, разбросанных по диску в следующем живописном порядке: 342573h – 3425ABh; 0211E5h – 212F9h; 0300AAh – 300ECh. Остается только прочитать его с диска!

Начиная с версии 3.0 NTFS поддерживает разряженные (sparse) атрибуты, т. е. такие, которые не записывают на диск кластеры, содержащие одни нули. При этом поле номера начального кластера отрезка может быть равным нулю, что означает, что данную отрезку не выделен никакой кластер. Поле длины содержит количество кластеров, заполненных нулями. Их не нужно считывать с диска. Вы должны самостоятельно изготовить их в памяти. Кстати говоря, далеко не все дисковые доктора знают о существовании разряженных атрибутов (если атрибут разряжен его флаг равен 8000h), и интерпретируют нулевую длину поля номера начального кластера весьма странным образом. Последствия такого "лечения" обычно оказываются очень печальны.

формат MBR

смещение

разм.

назначение

000

1BE

1CE

1DE

1EE

byte

флаг активного загрузочного раздела. (Boot Indicator)

80h – загрузочный раздел, 00h – не загрузочный

001

1BF

1CF

1DF

1EF

стартовая головка раздела

002

1C0

1D0

1E0

1F0

byte

стартовый сектор раздела (биты 0 – 5)

старшие биты стартового цилиндра (биты 6-7)

003

1C1

1D1

1E1

1F1

byte

младшие биты стартового цилиндра (биты 0-7)

004

1C2

1D2

1E2

1F2

byte

идентификатор системы (Boot ID), см. таблицу.4

005

1C3

1D3

1E3

1F3

byte

конечная головка раздела

006

1C4

1D4

1E4

1F4

byte

конечный сектор раздела (биты 0 – 5)

старшие биты конечного цилиндра (биты 6-7)

007

1C5

1D5

1E5

1F5

младшие биты конечного цилиндра (биты 0-7)

008

1C6

1D6

1E6

1F6

dword

смещение раздела относительно начала таблицы разделов в секторах

00С

1CA

1DA

1EA

1FA

dword

кол-во секторов раздела

структура файловой ссылки (file reference)

Первые 12 записей в MFT всегда занимают служебные метафайлы: $MFT (собственно, сам $MFT), $MFTMirr (зеркало $MFT), $LogFile (файл транзакций), $Volume (сведения о дисковом томе), $AttrDef (определенные атрибуты), '.' (корневой каталог), $Bitmap (карта свободного пространства), $Boot (системный загрузчик), $BadClus (перечень плохих кластеров) и т. д. Подробнее см. таблицу 11.

Первый четыре записи настолько важны, что продублированы в специальном $MFTMirr-файле, находящимся приблизительно посередине диска (точное расположение хранится в boot-секторе по смещению 38h байт от его начала). Вопреки своему названию, $MFTMirr это отнюдь не зеркало всего $MFT-файла, это всего лишь копия первых четырех элементов.

Записи с 12 по 15 помечены как используемые, но в действительности же они пусты (как нетрудно догадаться это задел на будущее). Записи с 16 по 23 не задействованы и честно помечены как неиспользуемые.

Начиная с 24 записи располагаются пользовательские файлы и каталоги. Четыре метафайла, появившихся в W2K – $ObjId, $Quota, $Reparse и $UsnJrnl – могут располагаться в любой записи, номер которой равен 24 или больше (как мы помним, номера файловых записей отсчитываются, начиная с нуля).

Для знакомства с MFT запустим DiskExplorer от Runtime Software, не забывая о том, что он требует прав администратора, в меню "File" найдем пункт "Drive" и в открывшемся диалоговом окне выберем логический диск, который мы хотим редактировать. Затем в меню "Goto" выберем пункт "Mft", заставляя DiskExplorer перейти к MFT, автоматически меняя режим отображения на наиболее естественный (см. рис. 3). Как вариант можно нажать <F6> (View as File Entry) и промотать несколько первых секторов клавишей <Page Down>.

Для каждого из файлов DiskExplorer сообщает:

1) номер сектора, к которому данная файловая запись принадлежит (обратите внимание, что номера секторов монотонно увеличиваются на 2, подтверждая тот факт, что размер одной файловой записи равен 1 Кбайту, однако, вы можете столкнуться и с другими значениями). Для удобства информация отображается сразу в двух системах исчисления – шестнадцатеричной и десятичной;

2) основное имя файла/каталога (т.е. имя файла из заголовка файловой записи, некоторые файлы имеют несколько альтернативных имен, подробнее см. "атрибуты"). Если имя файла/каталога зачеркнуто, значит он был удален, но соответствующая ему файловая запись все еще цела. Чтобы извлечь файл с диска (не важно удаленный или нет) подведите к нему курсор и нажните <Ctrl-T> для просмотра его содержимого в шестнадцатеричном виде или <Ctrl-S> для сохранения файла на диск. Тоже самое можно сделать и через контекстное меню (раздел "recovery"). При нажатии на <Ctrl-C> в буфер обмена копируется последовательность кластеров, занятых файлом (например, "DISKEXPL:K:1034240-1034240").
3) тип файловой записи – файл это или каталог?
4) атрибуты файла/каталога – a = архивный файл, r = только на чтение, h = скрытый, s = системный, l = метка тома, d = каталог, c = сжатый файл;
5) размер файла в байтах в десятичной системе исчисления (не для каталогов!);
6) дату и время модификации файла/каталога;
7) номер первого кластера файла/каталога (или "resident" для полностью резидентных файлов/каталогов);
8) перечень типов NTFS-атрибутов, имеющихся у файла/каталога, записанных в шестнадцатеричной нотации (обычно эта строка имеет вид 10 30 80 – атрибут стандартной информации, атрибут имени и атрибут данных файла, подробнее см. "типы атрибутов");
9) индекс файловой записи в MFT, выраженный в шестнадцатеричной и десятичной системах исчисления и следующий за словом "No:" (cсокращение от Number – номер);
10) индекс файловой записи материнского каталога, выраженный в шестнадцатеричной и десятичной системах исчисления (5h – если файл принадлежит к корневому каталогу). Для быстрого перемещения по файловым записям выберите в меню "Goto" пункт "Mft no" и введите требуемый индекс в шестнадцатеричной или десятичной форме;
11) для нерезидентных файлов/каталогов – перечень кластеров, занятых файлов в не декодированном виде (а зря – могли бы и декодировать!). Схема кодирования кластеров подробно описана в "списки отрезков".
Прежде чем продолжать чтение статьи, попробуйте поэкспериментировать в MFT файлами (особенно фрагментированными). Посмотрите как создаются и удаляются записи из MFT. Лучше всего это делать на диске, содержащим небольшое количество файлов/каталогов. Чтобы не форматировать логический диск, создайте виртуальный (благо количество оперативной памяти современных компьютеров это позволяет).

формат partition

Boot ID		тип раздела
00h		раздел свободен
0x01		FAT12 (менее чем 32.680 секторов в томе или 16 Мбайт)
0x04		FAT16 (32,680-65,535 секторов или 16-33 Мбайт)
0x05		расширенный раздел (extended partition)
0x06		BIGDOS FAT16 раздел (33 Мбайт – 4 Гбайт)
0x07		NTFS-раздел
0x0B		FAT32 раздел
0x0C		FAT32 раздел с поддержкой расширенной BIOS INT 13h
0x0E		BIGDOS FAT16 раздел с поддержкой расширенной BIOS INT 13h
0x0F		расширенный раздел с поддержкой расширенной BIOS int 13h
0x12		EISA раздел
0x42		динамический диск
0x86		legacy FT FAT16 раздел
0x87		legacy FT NTFS раздел
0x8B		Legacy FT volume formatted with FAT32 *
0x8C		Legacy FT volume using BIOS INT 13h extensions formatted with FAT32

возможные значения Boot ID

Sector Inspector Copyright Microsoft Corporation 2003

===========================================================================

Target - \\.\PHYSICALDRIVE0

1867 Cylinders

255 Heads

63 Sectors Per Track

512 BytesPerSector

12 MediaType

LBN 0 [C 0, H 0, S 1]

===========================================================================

Master Boot Record

===========================================================================

| B | FS TYPE | START | END | | |

| F | (hex) | C H S| C H S| RELATIVE | TOTAL |

===========================================================================

| * | 07 | 0 1 1| 764 254 63| 63| 12289662|

| | 0f | 765 0 1|1023 254 63| 12289725| 17687565|

| | 00 | 0 0 0| 0 0 0| 0| 0|

===========================================================================

LBN 12289725 [C 765, H 0, S 1]

===========================================================================

Extended Boot Record

===========================================================================

| B | FS TYPE | START | END | | |

| F | (hex) | C H S| C H S| RELATIVE | TOTAL |

===========================================================================

| | 07 | 765 1 1|1023 254 63| 63| 8193087|

| | 05 |1023 0 1|1023 254 63| 8193150| 4096575|

| | 00 | 0 0 0| 0 0 0| 0| 0|

строение NTFS boot-сектора

В начале всякого сектора расположена трехбайтовая машинная команда перехода на bootstrap code (обычно EB 52 90, хотя возможны и вариации). Так происходит потому, что при загрузке boot-сектора в память управление передается на его первый байт, а bootstrap код по туманным историческим соображениям был отодвинут в конец сектора (для NTFS верхняя граница составляет 54h байт), вот и приходится прыгать блохой!

С третьего по одиннадцатый байты (считая от нуля) хранится идентификатор производителя, определяющий тип и версию используемой файловой системы (например, "MSDOS5.0 " для FAT16, "MSWIN4.0"/"MSWIN4.1" для FAT32 и "NTFS " для NTFS). Если это поле окажется искажено, драйвер не сможет смонтировать диск и даже может посчитать его не отформатированным! (примечание: с FAT-дисками Windows 2000 будет работать даже с запорченным OEM ID, чего не скажешь про NTFS).

Следом за идентификатором расположен 25-бйтовый блок параметров BIOS (BIOS Parameter Block или сокращенно BPB), хранящий сведения о геометрии диска (число цилиндров, головок, секторов, размер сектора, кол-во секторов в кластере и т. д.). Если эта информация окажется утеряна или искажена, нормальное функционирования драйвера файловой системы станет невозможным. Причем, если данные число цилиндров/головок/секторов дублирует информацию, содержащуюся в MBR, а при ее утере элементарно восстанавливается описанным выше способом, то размер кластера определить не так-то просто! Позже мы обсудим этот вопрос более подробно, пока же ограничимся следующей табличкой, сообщающий размер кластера NTFS-томов, выбираемой штатной утилитой форматирования по умолчанию (см. таблицу 7)

При выборе размера кластера вручную, Windows 2000 поддерживает следующий модельный ряд: 1 сектор, 2 сектора, 4 сектора, 8 секторов, 16 секторов, 32 сектора, 64 сектора и 128 секторов. Чем больше размер кластер, тем меньше фрагментация и выше предельно адресуемый дисковый объем, но вместе с тем и выше потери от грануляции. Впрочем, ручное задание размеров кластера встречается достаточно редко.

размер диска	размер кластера
< 512MB	1 сектор
< 1GB	2 сектора
< 2GB	4 сектора
> 2GB	8 секторов

размер кластера, выбираемый Windows 2000 по умолчанию

К блоку параметров BIOS вплотную примыкает его продолжение – extended BPB, хранящий номер первого кластера MFT, ее размер в кластерах, номер кластера с зеркалом MFT и некоторую другую информацию. В отличии от FAT16/32, MFT может располагаться в любом месте диска (для борьбы с BAD-секторами это актуально). При нормальном развитии событий MFT располагается практически в самом начале диска (где-то в районе 4 кластера) и если только она не была перемещена ее легко найти глобальным поиском (строка "FILE*" по смещению 0 от начала сектора). При разрушении или некорректном заполнении extend PBP, драйвер файловой системы отказывается монтировать раздел, объявляя его не отформатированным.

Следом за extend PBP идет Bootstrap Code, который ищет на диске операционный загрузчик (у Windows NT это ntldr), загружает его в память и передает ему управление. Если Bootstrap Code отсутствует, загрузка операционной системы становится невозможной, однако, при подключении восстанавливаемого диска вторым, раздел должен быть прекрасно виден. Порча Bootstrap Code кода вызывает перезагрузку компьютера или его зависание.

И завершает boot-сектор уже известная нам сигнатура 55h AAh, без которой он ни за что не будет признан загрузочным.

смещение	размер	назначение
0x00	3 bytes	инструкция перехода
0x03	8 байт	OEM ID
0x0B	WORD	байт на сектор (для жестких дисков всегда 512)
0x0D	BYTE	секторов на кластер
0x0E	WORD	кол-во зарезервированных секторов, всегда (?) равно 0
0x10	3 BYTES	не используется NTFS и всегда должно быть равно 0
0x13	WORD	не используется NTFS и всегда должно быть равно 0
0x15	BYTE	медиа дескрпитор для жестких дисков всегда равен 0xF8
0x16	WORD	не используется NTFS и всегда должно быть равно 0
0x18	WORD	кол-во секторов в треке
0x1A	WORD	кол-во головок
0x1C	DWORD	кол-во скрытых секторов
0x20	DWORD	не используется NTFS и всегда должно быть равно 0
0x24	DWORD	не используется NTFS и всегда должно быть равно 0
0x28	8 байт	общее количество секторов (total sector)
0x30	8 байт	логический номер кластера, с которого начинается MTF
0x38	8 байт	логический номер кластера, с которого начинается зеркало MTF
0x40	DWORD	кол-во кластеров на сегмент (File Record Segment)
0x44	DWORD	кол-во кластеров на блок индексов (index block)
0x48	8 байт	серийный номер тома
0x50	DWORD	контрольная сумма (0 – не подсчитывать).
0x54	426 bytes	Bootstrap Code
0x01FE	WORD	55 AA

Техника восстановления файлов

Начнем с грустного. Поскольку, при удалении файла ссылки на 12первых блоков и 3 блока косвенной адресации необратимо затираются, автоматическое восстановление данных невозможно в принципе. Найти удаленный файл можно только по его содержимому. Искать, естественно, необходимо в свободном пространстве. Вот тут-то нам и пригодятся карты, расположенные за концом описателя группы цилиндров.

Если нам повезет и файл окажется нефрагментированным (а на UFS, как уже отмечалось, фрагментация обычно отсутствует или крайне невелика), остальное будет делом техники. Просто выделяем группу секторов и записываем ее на диск, но только ни в коем случае не на сам восстанавливаемый раздел! (Например, файл можно передать на соседнюю машину по сети). К сожалению, поле длины файла безжалостно затирается при его удалении и актуальный размер приходится определять "на глазок". Звучит намного страшнее, чем выглядит. Неиспользуемый хвост последнего фрагмента всегда забивается нулями, что дает хороший ориентир. Проблема в том, что некоторые типы файлов содержат в своем конце некоторое количество нулей, при отсечении которых их работоспособность нарушается, поэтому тут приходится экспериментировать.

А если файл фрагментирован? Первые 13 блоков (именно блоков, а не фрагментов!) придется собирать руками. В идеале это будет один непрерывный регион. Хуже, если первый фрагмент расположен в "чужом" блоке (т. е. блоке частично занятом другим файлом), а оставшиеся 12 блоков находятся в одном или нескольких регионах. Вообще-то достаточно трудно представить себе ситуацию, в которой первые 13 блоков были бы сильно фрагментированы (а поддержка фоновой дефрагментации в UFS на что?) Такое может произойти только при интересной "перегруппировке" большого количеств файлов, что в реальной жизни практически никогда не встречается (ну разве только что вы задумали навести порядок на своем жестком диске). Короче, будем считать, что 13'й блок файла найден. В массив непосредственной адресации он уже не влезает (там содержатся только 12 блоков) и ссылка на него, как и на все последующие блоки файла, должна содержаться в блоках косвенной адресации, которые при удалении файла помечается как свободные но не затирается, точнее затираются, но не сразу. Большинство файлов обходятся только одним косвенным блоком, что существенно упрощает нашу задачу.

Как найти этот блок на диске? Вычисляем смещение 13'го блока файла от начала группы цилиндров, переводим его в фрагменты, записываем получившееся число задом наперед (так, чтобы младшие байты располагались по меньшим адресами) и осуществляем контекстный поиск в свободном пространстве.

Отличить блок косвенной адресации от всех остальных типов данных очень легко — он представляет собой массив указателей на блоки, а в конце идут нули. Остается только извлечь эти блоки с диска и записать их в файл, обрезая его по нужной длине. Внимание! Если вы нашли несколько "кандидатов" в блоки косвенной адресации, это означает, что 13'й блок удаленного файла в разное время принадлежал различным файлам (а так, скорее всего и будет). Не все косвенные блоки были затерты, вот ссылки и остались. Как отличить "наш" блок от "чужих"? Если хотя бы одна из ссылок указывает на уже занятый блок данных (что легко определить по карте), такой блок можно сразу откинуть. Оставшиеся блоки перебираются вручную до получения работоспособной копии файла. Имя файла (если оно еще не затерто) можно извлечь из директории. Естественно, при восстановлении нескольких файлов мы не можем однозначно сказать какое из имен какому файлу принадлежит, тем не менее это все же лучше, чем совсем ничего. Директории восстанавливаются точно так же как и обыкновенные файлы, хотя по правде говоря, в них кроме имен файлов нечего восстанавливать…

Техника восстановления удаленных файлов

В ext2fs полное восстановление даже только что удаленных файлов, невозможно. В этом смысле она проигрывает как FAT, так и NTFS. Как минимум теряется имя файла. Точнее говоря, теряется связь имен файлов с их содержимым. При удалении небольшого количества хорошо известных файлов это еще терпимо (имена-то ведь сохранились!), но что делать, если вы удалили несколько служебных подкаталогов, в которых никогда ранее не заглядывали?

Достаточно часто inod'ы назначаются в том же порядке, в котором создаются записи в таблице директорий, к тому же существует такая штука как "расширения" (.c, .gz, .mpg и т.д.), так количество возможных комбинаций соответствий чаще всего бывает относительно небольшим. Тем не менее, восстановить удаленный корневой каталог в автоматическом режиме никому не удастся (а вот NTFS с этим справляется без труда).

В общем случае, стратегия восстановления выглядит приблизительно так: сканируем таблицу inode и отбираем все записи, чье поле i_links_count равно нулю. Сортируем их по дате удаления, чтобы файлы, удаленные последними, оказались наверху списка. Как вариант, можно просто наложить фильтр (мы ведь помним примерное время удаления, не правда ли?). Если соответствующие inod'ы еще не затерты вновь создаваемыми файлами, извлекаем список прямых/косвенных блоков и записываем их в дамп, корректируя его размер с учетом "логического" размера файла, за которое отвечает поле i_size.

Типы атрибутов

NTFS поддерживает больше количество предопределенных типов атрибутов, перечисленных в таблице8. Как уже говорилось выше, тип атрибута определяет его назначение и формат представления тела. Полное описание всех атрибутов заняло бы очень много места и поэтому здесь приводятся лишь наиболее "ходовые" из них, а за информацией об остальных обращайтесь к Linux-NTFS Project.

значение	ОС	условное обозначение	описание
010h	любая	$STANDARD_INFORMATION	стандартная информация о файле (время, права доступа)
020h	любая	$ATTRIBUTE_LIST	список атрибутов
030h	любая	$FILE_NAME	полное имя файла
040h	NT	$VOLUME_VERSION	версия тома
040h	2K	$OBJECT_ID	уникальный GUID и прочие ID
050h	любая	$SECURITY_DESCRIPTOR	дескриптор безопасности и списки прав доступа (ACL)
060h	любая	$VOLUME_NAME	имя тома
070h	любая	$VOLUME_INFORMATION	информация о томе
080h	любая	$DATA	основные данные файла
090h	любая	$INDEX_ROOT	корень индексов
0A0h	любая	$INDEX_ALLOCATION	ветви (sub-nodes) индекса
0B0h	любая	$BITMAP	карта свободного пространства
0C0h	NT	$SYMBOLIC_LINK	символическая связь
0C0h	2K	$REPARSE_POINT	для сторонних производителей
0D0h	любая	$EA_INFORMATION	расширенные атрибуты для HPFS
0E0 h	любая	$EA	расширенные атрибуты для HPFS
0F0h	NT	$PROPERTY_SET	устарело и ныне не используется
100h	2K	$LOGGED_UTILITY_STREAM	используется шифрованной файловой системой (EFS)

Unformat для NTFS

крис касперски ака мыщъх, np-email

- Я у вас тут винчестер недавно купил. Так вот, он сдох!

- Гарантия какая?

- Пожизненная.

- Раз сдох, значит, гарантия кончилась.

разговор продавца с покупателем

случилось самое страшное: вы потеряли весь NTFS-раздел целиком. случайно отформатировали или пережили разрушительный дисковый сбой. где-то там остались миллиарды байт бесценных данных теперь уже недоступных операционной системе. как вернуть информацию к жизни? в этой статье ### главе автор делится советами ручного и автоматического восстановления.

Внутри FILE_DISPOSITION_INFORMATION

IRP_MJ_SET_INFORMATION/ FILE_DISPOSITION_INFORMATION – это пакет, посылаемый драйверу при удалении файла (имейте это ввиду при дизассемблировании). Чтобы уметь восстанавливать удаленные файлы, необходимо отчетливо представлять, что происходит в процессе удаления файла с NTFS-раздела, а происходит при этом следующее:

q корректируется файл /$MFT:$BITMAP, каждый бит которого определяет "занятость" соответствующей файловой записи (FILE Record) в MFT ("0" – запись не используется);

q корректируется файл /$BITMAP, каждый бит которого определяет "занятость" соответствующего кластера ("0" – кластер не используется);

q файловые записи, соответствующие файлу, помечаются как удаленные (поле FLAG, находящееся по смещению 16h от начала FILE Record сбрасывается в ноль);

q ссылка на файл удаляется из двоичного дерева индексов (технические подробности этого животрепещущего процесса здесь опускаются, поскольку восстановить таблицу индексов вручную сможет только гуру, да и зачем? в NTFS индексы играют вспомогательную роль – проще переиндексировать директорию заново, чем восстанавливать сбалансированное B*tree дерево);

q обновляется атрибут $STANDART_INFORMATION каталога, хранившего удаляемый файл (время последнего доступа и т. д.);

q в /$LogFile обновляется Sequence Number (изменения, происходящие в журнале транзакций мы не рассматриваем);

q Update Sequence Number следующих файловых записей увеличивается на единицу: сам удаляемый файл, текущий каталог, /$MAF, /$MFT:$BITMAP, /$BITMAP, /$BOOT, /$TRACKING.LOG

Каталоги удаляются практически точно так же, как и файлы (с точки зрения файловой системы, каталог тоже файл, только особый – с двоичным B*tree деревом индексов внутри).

Ни в том, ни в другом случае физического удаления файла не происходит и он может быть легко восстановлен до тех пор, пока не будет затерта принадлежащая ему FILE Record, хранящая резидентное тело файла или список отрезков (run-list) нерезидентного содержимого. Утрата FILE Record очень неприятна, поскольку в этом случае файл придется собирать по кусочкам руками и чем сильнее он фрагментирован – тем сложнее эта задача. В отличии от FAT, NTFS не затирает первого символа именем файла, чем значительно упрощает свое восстановление.

Восстановление данных на NTFS разделах

крис касперски

эта статья открывает цикл публикаций, посвященный ручному восстановлению данных на NTFS-дисках без использования автоматизированных "докторов", зачастую только добивающих "пациента" вместо его лечения. мы коснемся всех аспектов проблемы – логические и физические дефекты, жесткие диски и съемные носители (CD-ROM, ZIP, магнитооптика, FLASH…), программные и аппаратные RAID-массивы и т. д. сегодня мы рассмотрим основные концепции хранения и организации данных на жестких дисках и поговорим о восстановлении загрузочных областей (таблицы разделов, boot-секторов) на обычных и динамических разделах.

При переформатировании диска, операционные системы

При переформатировании диска, операционные системы семейства NT никогда не изменяют тип файловой системы (разве что попросить их это сделать явно), поэтому непреднамеренное форматирование NTFS раздела в FAT16/32 крайне маловероятно. Windows9x/MS-DOS, напротив, любой диск стремятся отформатировать под FAT16/32, не замечая, что на нем что-то уже находится. Непреднамеренная порча NTFS-разделов при установке Windows 9x/MS-DOS поверх Windows NT – обычное дело, через которое проходит уже второе поколение пользователей.

Стратегия спасения данных во всем похожа на восстановление NTFS-тома, отформатированного под NTFS, с той лишь разницей, что при создании таблицы размещения файлов (file allocation table), первые несколько тысяч файловых записей в MFT затираются безвозвратно (впрочем, их еще можно собрать руками, действуя по методике описанной в разделе "разгребая кластерные обломки" предыдущей статьи этого цикла).

Файлы, с уцелевшей FILE RECORD легко восстанавливаются R-Studio/GetDataBack/EasyRecovery. Для ручного восстановления всего тома его необходимо заново отформатировать под NTFS, предварительно определив количество секторов в кластере. Далее действуем по плану — увеличиваем размер $MFT, пускаем chkdsk и собираем все, что только можно собрать. Поскольку количество файлов, хранящихся на современных дисках, зачастую исчисляется многими миллионами, потеря первой тысячи из них не так уж и страша (если только по закону подлости это не будут самые ценные файлы).

Восстановление NTFS– undelete своими руками

крис касперски ака мыщъх, no eamil

Меня смущает то, что сырые продукты создаются на интуиции и на гениальности их создателей. Но ведь за ними остается выжженная земля! Если OS/360 оставила за собой шлейф идей, людей, что оставляет за собой Windows?

Алексей Бабий

"Из жизни первобытных программистов"

продолжая говорить о NTFS, сегодня мы рассмотрим технику восстановления удаленных файлов с помощью простейшего дискового редактора (типа Disk Probe) и утилиты chkdsk, а так же дадим несколько советов по поводу создания собственного инструментария, который может быть запрограммирован на любом языке, имеющим доступ к win32 API.

Восстановление после тяжелых разрушений

В результате сбоя содержимое дискового тома может стать недоступно операционной системе и при попытке чтения его оглавления будет выдаваться сообщения в стиле "Файл или папка повреждены. Чтение невозможно", "Нет доступа к диску", "Системе не удается найти логическое устройство" и т.д. Chkdsk говорит, что "Повреждена основная таблица файлов" и прекращает работу. Караул! Верните мой том! #### Пиво, водка и вобла гарантируется!

Не паникуйте! Попробуйте запустить NTExplorer и посмотрите, что он покажет. Маловероятно, чтобы содержимое всего тома было утеряно целиком (это же что такое с ним нужно было сделать?!). Если хотя бы часть файловых записей уцелела, R-Studio/GetDataBack/EasyRecovery их обязательно восстановят!

Анализ показывает, что основной причиной по которой chkdsk отказывается проверять том обычно становится порча файловой записи, описывающей $MFT. Если в процессе обновления $MFT внезапно отключить питание — такой исход событий вполне вероятен, особенно на жестких дисках с емким аппаратным кэшем — они не успевают завершить сохранение секторов на энергии, накопленной в конденсаторах, а вот их младшие собраться с этим справляются. Тоже самое происходит при неудачном перемещении $MFT файла или физическом разрушении первого MFT-сектора. Зеркальная копия $MFT во всех этих случаях остается цела, однако chkdsk по каким-то таинственным причинам не хочет ей пользоваться и вы должны восстановить ее самостоятельно. Просто скопируйте первый сектор $MFTMirr в первый сектор $MFT и громко скажите "ниндзя"! Поклонники Sector Inspector'а могут воспользоваться командным файлов следующего содержания.

SECINSPECT.EXE -backup d: backup.dsk XXX 1

SECINSPECT.EXE –restore d: backup.dsk YYY CONFIRM

Восстановление при помощи debugfs

Загружаем в отладчик редактируемый раздел или его копию, "debugfsmy_dump" или "debugfs /dev/sdb1". Если мы планируем осуществлять запись на диск, необходимо указать ключ "–w" ("debugfs —w my_dump" или "debugfs —w /dev/sdb1".

Чтобы просмотреть список удаленных файлов даем команду "lsdel" (или "lsdel t_sec", где t_sec количество секунд, прошедшее со момента удаления файла). Экран заполняется список удаленных файлов. Естественно без имен. Файлы, удаленные более, чем t_sec секунд назад (если sec задан) в этот список не попадают.

Команда "cat <N>", выводит содержимое текстового файла на терминал, где <N>, номер inod'ы, заключенный в угловые кавычки. При выводе двоичных файлов на экране творится черт знает что, и такие файлы должны сбрасываться в дамп командой "dump <N> new_file_name", где new_file_name новое имя файла (с путем), под которым он будет записан в нативную (native) файловую систему, т. е. ту файловую систему из-под которой был запущен debugfs. Файловая система восстанавливаемого раздела при этом остается неприкосновенной. Другими словами, наличие ключа "--w" для этого не требуется.

При желании можно восстановить файл непосредственно на самой восстанавливаемой файловой системе (что особенно удобно при восстановлении больших файлов). В этом нам поможет команда "undel <N> undel_file_name", где undel_file_name — имя, которое будет присвоено файлу после восстановления. Внимание! Когда будете это делать, помните, что команда undel крайне агрессивна и деструктивна по своей природе. Она затирает первую свободную запись в таблице директорий, делая восстановление оригинальных имен невозможным!

Команда "stat <N>" отображает содержимое inod'ы в удобочитаемом виде, а команда "mi <N>" позволяет редактировать их по своему усмотрению. Для ручного восстановления файла (которого не пожелаешь и врагу) мы должны установить счетчик ссылок (link count) в единицу, а время удаления (deletion time), наоборот, сбросит в нуль. Затем отдать команду "seti <N>", помечающую данную inod'у как используемую, и для каждого из блоков файла выполнить "setb X", где X – номер блока (перечень блоков, занимаемых файлов, можно подсмотреть командой stat, причем, в отличии от lde она отображает не только непосредственные, но и косвенные блоки, что несравненно удобнее). Остается только дать файлу имя, что осуществляется путем создания каталожной ссылки (directory link), а делает это команда "ln <N> undel_file_name", где undel_file_name – имя, которое будет дано файлу после восстановления, при необходимости с путем. (Внимание! создание каталожных ссылок необратимо затирает оригинальные имена удаленных файлов). После этого полезно дать команду "dirty", чтобы файловая система была автоматически проверка при следующей загрузке, или выйти из отладчика и вручную запустить fsck с ключом "–f", форсирующим проверку.

Теперь перейдем к восстановлению оригинального имени. Рассмотрим простейший случай, когда директория, содержащая удаленный файл (так же называемая материнской директорией) все еще цела. Даем команду "stat dir_name" и запоминаем номер inode, который нам сообщат. Говорим отладчику "dump <INODE> dir_file", где INODE – номер сообщенной inod'ы, dir_file имя файла нативной файловой системы, в которую будет записан дамп. Загружаем полученный дамп в hex-редактор и просматриваем его содержимое в "сыром" виде. Все имена будет там. При желании можно написать утилиту-фильтр, выводящую только удаленные имена. На Perl'е это не замет и десяти минут.

А как быть если материнская директория тоже удалена? Тогда она и будет помечена удаленной! Выводим список удаленных inod'е, отбираем из них директории, формируем перечень принадлежащих им блоков и дампим в файл, просматриваемый вручную или с помощью утилиты-фильтра. Как уже отмечалось, порядок расположения файлов в inod'е очень часто совпадает с порядком расположения файлов в директории, поэтому восстановление оригинальных имен в четырех из пяти случаев проходит на ура.

При тяжких разрушениях, когда восстанавливаемый файл приходится собирать по кусочкам, помогает команда "dump_unused", выводящая на терминал в все неиспользуемые блоки. Имеет смысл перенаправить вывод в файл, запустить hexedit и покопаться в этой куче хлама — это по крайней мере проще, чем лазить по всему диску (на дисках, заполненных более чем на три четверти, этот трюк сокращает массу времени).

Вывод: debugfs в значительной мере автоматизирует восстановление удаленных файлов (впрочем, до полного комфорта ему далеко), однако, восстановить файл с разрушенным inode он не способен и без lde здесь не обходится.

Восстановление при помощи lde

Открываем редактируемый раздел или его файловую копию: "lde my_dump" или "lde /dev/sdb1". Редактор автоматически определяет тип файловой системы (в данном случае ext2fs) и предлагает нажать any key для продолжения. Нажимаем! Редактор автоматически переключается в режим отображения супер-блока, и предлагает нажать для перехода в режим inode и для перехода в блочный режим (block-mode). Жмем и оказываемся в первой inod'e, описывающей корневой каталог. <Page Dowd> перемещает нас к следующей inod'e, а <Page Up> к предыдущей. Пролистываем inod'ы вниз, обращая внимание на поле LINKS. У удаленных файлов оно равно нулю и тогда "DELETION TIME" содержит время последнего удаления (мы ведь помним его, правда?). Обнаружив подходящую inod'у, перемещаем курсор к первому блоку в списке DIRECT BLOCKS (где он должен находиться по умолчанию) и нажимаем <F2>. В появившемся меню выбираем пункт "Block mode, viewing block under cursor" (или сразу нажимаем горячу клавишу <Shift-B>). Редактор перемещается на первый блок удаленного файла. Просматривая его содержимое в hex-режиме, пытаемся определить он ли это или нет. Чтобы возвратиться к просмотру следующей inod'ы, нажимаем , чтобы восстановить файл — <Shift-R>, затем еще раз <R> и имя файла-дампа для восстановления.

Можно восстанавливать файлы и по их содержимому. Допустим, нам известно, что удаленный файл содержит строку "hello, world". Нажимаем <f> и затем <A> (Search all block). Этим мы заставляем редактор искать ссылки на все блоки, в том числе и удаленные. Как вариант, можно запустить редактор с ключом "--all". Но так или иначе, мы нажимаем , и когда редактор перейдет в block-mode, давим </> и вводим ASCII-строку для поиска. Находим нужный блок. Прокручивая его вверх-вниз, убеждаемся, что он действительно принадлежит тому самому файлу. Если это так, нажимаем <Ctrl>+<R>, заставляя редактор просматривать все inod'ы, содержащие ссылку на этот блок. Номер текущей найденной inod'ы отображается внизу экрана. (Именно что внизу! Вверху отображается номер последней просмотренной inod'ы в режиме inod'e). Переходим в режим inod'е по клавише , нажимаем <#> и вводим номер inod'ы, которую хотим просмотреть. Если дата удаления более или менее соответствует действительности, нажимаем <Shift-R>/<R> для сброса файла на диск. Если нет — возвращаемся в block-mode и продолжаем поиск.

В сложных случаях, когда список прямых и/или косвенных блоков разрушен, восстанавливаемый файл приходится собирать буквально по кусочкам, основываясь на его внутреннем содержимом и частично — на стратегии выделения свободного пространства файловой системой. В этом нам поможет клавиша <w> — дописать текущий блок к файлу-дампу. Просто перебираем все свободные блоки один за другим (редактор помечает их строкой NOT USED), и обнаружив подходящий, дописываем в файл. Конечно, сильно фрагментированный бинарник так не восстановить, но вот листинг программы — можно вполне.

Вывод — ручное восстановление файлов с помощью lde крайне непроизводительно и трудоемко, зато наиболее "прозрачно" и надежно. А вот восстанавливать оригинальные имена лучше всего при помощи debugfs.

Восстановление при помощи R-Studio

Утилита R-Studio for NTFS, уже рассмотренная нами в предыдущих номерах журнала, вопреки своему названию, поддерживает не только NTFS, но и ext2fs/ext3fs. С точки зрения неквалифицированных пользователей это хорошее средство для автоматического восстановления удаленных файлов: интуитивно-понятный интерфейс, простое управление и прочие прелести прогресса. Файлы восстанавливаются несколькими щелчками. Правда без и имен и без каких-либо гарантий, что они вообще восстановятся. Ручное восстановление не поддерживается. Файлы с разрушенной inode не восстанавливаются, хотя под ext2fs, в отличии от NTFS это достаточно просто сделать!

В общем, для профессионального использования R-Studio катастрофически не подходит.

Восстановление удаленных файлов на ext2fs

Файловая система ext2fs все еще остается базовой файловой системой для многих Linux'ов, поэтому рассмотрим ее первой. Концепции, которые она исповедует, во многом схожи с NTFS, так что культурного шока при переходе с NTFS на ext2fs с нами не случится. Подробное описание структуры хранения данных ищите в документе "Design and Implementation of the Second Extended Filesystem", а так же книге Таненбаума "Operating Systems: Design and Implementation", электронную версию которой можно раздобыть в Осле. Исходные тексты дисковых утилит (драйвер файловой системы, lde, debugfs) так же не помешают.

Восстановление удаленных файлов на ext3fs

Файловая система ext3fs это ext2fs с поддержкой журналирования (в терминологии NTFS– транзакций). В отличие от ext2fs она намного бережнее относится к массиву директорий и при удалении файла, ссылка на inode уже не уничтожается, что упрощает автоматическое восстановление оригинальных имен. Однако, поводов для радости у нас нет никаких, поскольку в ext3fs перед удалением файла список принадлежащих ему блоков тщательно вычищается. Как следствие — восстановление становится невозможно. Ну… практически невозможно. Нефрагментированные файлы с более или менее осмысленным содержимым (например, исходные тексты программ) еще можно собрать по частям, но и времени на это уйдет… К счастью, косвенные блоки не очищаются, а, значит, мы теряем лишь первые 12 * BLOCL_SIZE байт каждого файла. На типичном 10 Гбайтном разделе BLOCK_SIZE обычно равен 4- или 8 Кбайтам, т. е. реальные потери составляют менее 100 Кбайт. По современным понятиям сущие пустяки! Конечно, без этих 100 Кбайт большинство файлов просто не запустятся, однако, недостающие 12 блоков найти на диске вполне реально. Если повезет, они окажутся расположенными в одном-двух непрерывных отрезках. Даже на сильно фрагментированных разделах, непрерывные отрезки из 6-12 блоков достаточно часто встречаются.

Как мы будем действовать? Необходимо найти хотя бы один блок, гарантированно принадлежащий файлу и при этом расположенных за границей в 100 Кбайт от его начала. Это может быть текстовая строка, копирайт фирмы да все что угодно! Короче, нам нужен номер блока. Пусть для определенности он будет равен 0x1234. Записываем его в обратном порядке так, чтобы младший байт располагался по меньшему адресу и выполняем поиск 34h 12h 00h 00h — именно это число будет присутствовать в косвенном блоке. Отличить косвенный блок от всех остальных блоков (например, блоков, принадлежащих файлам данных) очень легко — он представляет собой массив 32-битных номеров блоков более или менее монотонно возрастающих. Дважды и трижды косвенные блоки отыскиваются по аналогичной схеме.

Проблема в том, что одни и те же блоки в разное время могли принадлежать различным файлам, а, значит, и различным косвенным блокам. Как разобраться какой из них правильный? Да очень просто! Если хотя бы одна из ссылок косвенного блока указывает на уже занятый блок, данный косвенный блок принадлежит давно удаленному файлу и нам совсем не интересен.

Кстати говоря, debugfs довольно криво поддерживает ext3fs. В частности, команда lsdel всегда показывает ноль удаленных файлов, даже если грохнуть ### удалить весь раздел. Так что вопрос выбора файловой системы отнюдь не так прост, каким его пытаются представить книги "LINUX для начинающих", а преимущества ext3fs на рабочих станциях и домашних компьютерах далеко небесспорны и неочевидны. Поддержка транзакций реально требуется лишь серверам (да и то не всем), а вот невозможность восстановления ошибочного удаленных файлов зачастую приносит намного большие убытки, чем устойчивость файловой к внезапным отказам питания.

Восстановление удаленных файлов под BSD

крис касперски

статья описывает структуру файловых систем типа FFS/UFS1/UFS2 и рассказывает о методиках ручного восстановления удаленных файлов. материал ориентирован на квалифицированных пользователей, администраторов и системных программистов, работающих под BSD-подобными системами.

командной строке посвящается…

Восстановление удаленных файлов под Linux

крис касперски

каждый из нас хотя бы однажды удалял ценный файл (а то и весь корневой каталог целиком!). резервной копии нет. времени на поиски утилит для восстановления — тоже. как быть? к счастью, все необходимое уже включено в ваш любимый дистрибьютив и всегда находится под рукой. если говорить кратко: debugfs, lsdel, stat, cat, dump, undel. если чуть подлиннее — читайте эту статью, рассказывающую о восстановлении данных на ext2fs и отчасти ext3fs разделах.

>>> Врезка чем восстанавливать?

Копания Stellarinfo (stellarinfo.com) выпустила утилиту "Phoenix", предназначенную для восстановления данных и поддерживающую практически все популярные файловые системы, которые только известны на сегодняшний день (и UFS в том числе). Демонстрационную копию можно сказать по адресу http://www.stellarinfo.com/spb.exe. Обратите внимание на расширение файла. Это exe. Судя по графе "Platform Supported" он рассчитан на BSD. Ага, так он в BSD и запустится! Потребуется устанавливать в систему дополнительный винчестер с рабочей Windows и инсталлировать Phoenix поверх нее. Под WindowsPE он работать отказывается… На Windows 2000 запускается, но при попытке анализа заведомо исправного раздела падает с воплем о критической ошибке. На других системах я его не проверял. Тем не менее, ссылку на файл все-таки даю. Во-первых, пусть все знают, что это за зверь и особых надеж на него не возлагают, а во-вторых, не исключено что у кого-то он все-таки сработает.

>>> Врезка что читать

q Design and Implementation of the Second Extended File system

o подробное описание файловой системы ext2fs от самих разработчиков проекта. на английском языке. http://e2fsprogs.sourceforge.net/ext2intro.html;

q Linux Ext2fs Undeletion mini-HOWTO

o краткая, но доходчивая инструкция по восстановлению удаленных файлов на ext2fs разделах. на английском языке. http://www.praeclarus.demon.co.uk/tech/e2-undel/howto.txt;

q Ext2fs Undeletion of Directory Structures mini-HOWTO

o краткое руководство по восстановлению удаленных директорий на ext2fs разделах. на английском языке: http://www.faqs.org/docs/Linux-mini/Ext2fs-Undeletion-Dir-Struct.html;

q HOWTO-undelete

o еще одно руководство по восстановлению удаленных файлов на ext2fs разделах с помощью редактора lde. на английском языке. http://lde.sourceforge.net/UNERASE.txt;

>>>> Врезка фрагментация и ее исследование

Существуют по меньшей мере две методики исследования стратегии выделения дискового пространства: статическая и динамическая. В первом случае мы просто запускаем дисковый редактор (предпочтительно Disk Explorer от Runtime Software) и анализируем run-list'ы уже существующих файлов, записанных в различное время и различными способами (можно, например, скопировать файл с одного места в другое или попеременно увеличивать размер нескольких файлов – стратегии выделения свободного пространства в обоих случаях будут различны). Статический подход полезен тем, что дает бесценный статистический результат для всего тома целиком, однако, определяет лишь конечный результат, но не путь, которым он был достигнут.

>>>> Врезка источники угрозы

Почему погибают дисковые разделы? Ниже приводится список наиболее распространенных причини, отсортированный в порядке убывания их "популярности":

q ошибки оператора, вирусы, троянские программы;

q отключение питания/зависание системы во время интенсивных дисковых операций, сопровождаемых обновлением MFT (например, удаление/добавление файлов или каталогов);

q некорректное поведение различных дисковых утилит (Partition Magic, Ahead Nero, Norton Disk Doctor и т. д.);

q физические дефекты оперативной памяти, приводящие к нарушению целостности дискового кэша и как следствие — порче самого диска;

q некорректное поведение привилегированных драйверов, случайно или преднамеренно "залетающих" внутрь служебных структур NTFS-драйвера;

>>>> Врезка ничто так не постоянно, как временное

Если несмотря на все усилия восстановить удаленный файл так и не удается, попробуйте отыскать его резервную копию. Многие приложения создают такие копии, но не все афишируют их присутствие. Не стоит так же забывать о файле подкачки, временных файлах, дампе памяти и других источниках, которые могут хранить фрагменты восстанавливаемого файла (а иногда и весь файл целиком). Даже если они уже были удалены, возможно, принадлежащая им файловая запись еще не была затерта и восстановление не займет много времени.

>>>> Врезка первичная диагностика аварии

симптом			диагноз		лекарство
жесткий диск не опознается BIOS'ом			отказ электроники жесткого диска		–
операционная система не загружается, BIOS выдает надпись "non system disk", missing operation system или что-то в этом роде		при загрузки с дискеты логические диски не видны (команда C: дает ошибку)		повреждена таблица разделов или сигнатура 55hAAh		восстановите MBR вручную или при помощи GetDataBack
	логические разделы видны и исправны (команды C: и dir C: работают)		слетел boot и/или MBR загрузчик		запустите консоль восстановления и дайте команды FIXBMR и FIXBOOT
	логические разделы видны, но команда dir C: дает ошибку		поврежден boot-сектор или MTF		восстановите boot-сектор вручную или резервной копии, восстановите MFT из MFTMirr
операционная система начинает закружатся, но затем виснет или прерывается с сообщением об ошибке		команда dir C: выполняется нормально, chkdsk не находит ошибок		навернулась сама операционная система		переустановите операционную систему, предварительно скопировав все ценные файлы на другой носитель
	команда dir в одном или нескольких подкаталогах выводит мусор или показывает не все файлы		повреждена MTF или одна из ее дочерних структур		запустите Disk Explorer и прочитайте файлы из MFT напрямую в обход индексов
	некоторые файлы не читаются, при этом винчестер издает ритмичные скребущие звуи		физические повреждения поверхности диска		запустите утилиту восстановления жесткого диска от его производителя
	некоторые файлы содержат в себе фрагменты других файлов		на диске образовались пересекающиеся кластеры		запустите chkdsk
	свободное место на диске планомерно уменьшается без видимых причин		некоторые кластеры оказались потерянными		запустите chkdsk

>>>> Врезка полезные советы— план превентивных действий по спасению данных

Чтобы предотвратить разрушение тома и упростить задачу восстановления данных, рекомендуется заблаговременно выполнить следующий комплекс мероприятий:

q переместите $MFT подальше от начала раздела. Первые секторы раздела, как показывает практика, самое небезопасное место. Во-первых, сюда стремятся вирусы (миф о невозможности прямого доступа к диску под NT всего лишь миф — читайте описание функции CreateFile и инструкцию на ASPI32-драйвер), во-вторых, некоторые утилиты (и в частности Ahead Nero) при некоторых обстоятельствах путают жесткий диск с оптическим накопителем, записывая образ не "туда", а, значит, в первых ~700 Мбайтах физического диска (не логического тома!) не должно быть ничего ценного, в-третьих, если вы вдруг запустите WipeDisk или любую другую затирающую утилиту, первым погибнет именно $MFT, без которого весь дисковый том просто груда мусора, в четвертых… да много разных причин можно найти. Просто переместите $MFT, вам что — трудно? Достаточно взять любой дефрагментатор, распространяющийся в исходных текстах (энтузиасты! ау! присоединяйтесь к проекту http://sourceforge.net/projects/opendefrag/) и слегка доработать его "напильником" под наши нужды. Естественно, валерьянка и резервная копия обязательно должны быть под рукой!

q не допускайте фрагментации $MFT-файла! Не создавайте на диске огромного количества мелких файлов и не заполняйте его более чем на 90%. Стандартный дефрагментатор, входящий в комплект штатной поставки Windows 2000/XP, не позволяет дефрагментировать $MFT и приходится прибегать к сторонним средствам, лучшим из которых на мой взгляд является O&O Defrag Pro от одноименной компании (www.oo-software.com). Это действительно профессиональный дефрагментатор, к тому же поддерживающий командную строку;

q периодически создавайте резервную копию файловой записи $MFT — для этого достаточно сохранить один-единственный (!) сектор — первый сектор MFT, номер которого содержится в boot, только не забывайте его периодически обновлять, ведь при добавлении новых файлов/каталогов, MFT планомерно расширяется и старые списки отрезков становятся все менее и менее актуальны;

>>>> Врезка полезный совет

Как быстро узнать тип текущего раздела– FAT или NTFS? Да очень просто – достаточно попробовать создать в его корневом каталоге файл $mft – если он будет создан успешно, то это FAT и, соответственно, наоборот. Если файл $Extend будет создан успешно, то версия файловой системы 3.0 или выше.

>>>> Врезка проблема нулевой дорожки

Главная загрузочная запись жестко держит за собой первый сектор и если он вдруг окажется разрушенным, работа с таким диском станет невозможной. До недавнего времени проблема решалась посекторным копированием винчестера с переносом данных на здоровый жесткий диск с идентичной геометрией с последующий восстановлением MBR.

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

Механизм замещение секторов все еще не стандартизирован и осуществляются утилитами, предоставляемые производителем конкретной модели винчестера. Чаще всего они распространяются бесплатно и могут быть свободно найдены в сети.

0x0000 eb 2e 49 50 41 52 54 20-63 6f 64 65 20 30 30 39 ы.IPART code 009

0x0010 20 2d 20 49 6f 6d 65 67-61 20 43 6f 72 70 6f 72 - Iomega Corpor

0x0020 61 74 69 6f 6e 20 2d 20-31 31 2f 32 33 2f 39 30 ation - 11/23/90

0x0030 fa fc 8c c8 8e d0 bc 00-7c 8e d8 8e c0 b9 00 02 ·№МLО¦-.|О+ОL¦..

0x0040 bf 00 7e be 00 7c f3 a4-e9 00 02 fb bd 00 7e 8b ¬.~-.|єдщ..v-.~Л

0x0050 fd be be 01 b9 04 00 80-3a 80 74 0b 83 c6 10 e2 ¤--.¦..А:Аt.Г¦>т

0x0060 f6 8b b5 b2 01 eb 51 56-83 c6 10 49 e3 0b 80 3a ЎЛ¦-.ыQVГ¦>Iу.А:

0x0070 80 75 f5 8b b5 b0 01 eb-3f 5e 56 8a 12 8a 72 01 АuїЛ¦-.ы?^VК¦Кr.

0x0080 8a 4a 02 8a 6a 03 bb 00-7c be 05 00 56 b8 01 02 КJ.Кj.¬.|-..V¬..

0x0090 cd 13 73 0e 33 c0 cd 13-5e 4e 75 f0 8b b5 b4 01 =!s.3L=!^NuЁЛ¦+.

0x00a0 eb 16 5e be fe 7d 81 3c-55 aa 74 06 8b b5 b6 01 ы-^-¦}Б<Uкt.Л¦¦.

0x00b0 eb 06 5e 03 f5 e9 48 fd-e8 1b 00 8b b5 b8 01 e8 ы.^.їщH¤ш<.Л¦¬.ш

0x00c0 14 00 b4 00 cd 16 33 c0-8e c0 26 c7 06 72 04 34 ¶.+.=-3LОL&¦.r.4

0x00d0 12 ea f0 ff 00 f0 03 f5-ac 3c 00 74 0b 56 b4 0e ¦ъЁ .Ё.їм<.t.V+.

0x00e0 bb 07 00 cd 10 5e eb f0-c3 49 6e 76 61 6c 69 64 ¬..=>^ыЁ+Invalid

0x00f0аа 20 70 61 72 74 69 74 69-6f 6e 20 74 61 62 6c 65ааа partition table

0x0100аа 00 44 69 73 6b 20 69 73-20 6e 6f 74 20 62 6f 6fаа .Disk is not boo

0x0110аа 74 61 62 6c 65 00 45 72-72 6f 72 20 6c 6f 61 64аа table.Error load

0x0120аа 69 6e 67 20 6f 70 65 72-61 74 69 6e 67 20 73 79аа ing operating sy

0x0130аа 73 74 65 6d 00 4d 69 73-73 69 6e 67 20 6f 70 65аа stem.Missing ope

0x0140аа 72 61 74 69 6e 67 20 73-79 73 74 65 6d 00 0d 0aаа rating system...

0x0150аа 52 65 70 6c 61 63 65 20-61 6e 64 20 73 74 72 69аа Replace and stri

0x0160аа 6b 65 20 61 6e 79 20 6b-65 79 20 77 68 65 6e 20 ааke any key when

0x0170аа 72 65 61 64 79 0d 0a 00-00 00 00 00 00 00 00 00аа ready...........

0x0180аа 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00аа ................

0x0190аа 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00аа ................

0x01a0аа 00 00 00 00 00 00 00 00-00 00 00 00 00 00 45 06аа ..............E.

0x01b0аа e9 00 01 01 16 01 35 01-4e 01 6a 72 a5 d5 00 00аа •...-.5.N.jrх-..

0x01c0аа 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00аа ................

0x01d0аа 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00аа ................

0x01e0аа 00 00 00 00 00 00 00 00-00 00 00 00 00 00 80 01аа ..............L.

0x01f0аа 01 00 06 3f 20 5f 20 00-00 00 e0 ff 02 00 55 aaаа ...? _ ...Ё ..Uъ

практически ничем не отличаются от

простые (simple)               практически ничем не отличаются от обычных разделов, за исключением того, при переразбиении диска отпадает необходимость в перезагрузке. Базовый тип для всех остальных динамических дисков.

избыточность:                   нет

эффективность:                низкая

составные (spanned)        состоят из одного или нескольких simple-дисков, находящихся в различных разделах или даже устройствах, представленный как один логический диск. Данные на simple-диски пишутся последовательно (классический линейный RAID).

избыточность:                   нет

эффективность:                низкая

чередующиеся (stripped) тоже самое, что и spanned, но данные записываются параллельно на все simple-диски. при условии, что они расположены на различных каналах IDE-контроллера это значительно увеличивает скорость обмена данными. короче говоря, классический RAID уровня 0.

избыточность:                   нет

эффективность:                средняя

зеркальные (mirrored)   два simple-диска, расположенные на разных устройствах. данные дублируются на оба носителя (RAID уровня 1).

избыточность:                   средняя

эффективность:                средняя

чередующиеся с контролем четности (stripped with party): соответствует массиву RAID уровня 5. Состоит из трёх, или более дисков. Представляет из себя stripped volume с контролём ошибок. Данные пишутся на два диска, в два блока, а на третий диск, и в третий блок записывается ECC, код коррекции ошибок, с помощью которого, по информации любого из блоков можно востановить содержимое второго блока.

избыточность:                   высокая

эффективность:                высокая

зеркальный с чередованием (mirrored striped)

соответствует массиву RAID 1+0.

избыточность:                   средняя

эффективность:                высокая

>>>> Врезка версии NTFS

Служебные структуры файловой системы NTFS не остаются постоянными, а слегка меняются от одной версии WindowsNT к другой (см. таблицу 1). Этот факт следует принять во внимание при использовании автоматизированных "докторов". Попав на более свежую версию NTFS, "доктор", не оснащенный мощным AI, может запутаться в измененных структурах и разрушить вполне здоровый том.

версия NTFS	операционная система	условное обрзначение
1.2	Windows NT	NT
3.0	Windows 2000	W2K
3.1	Windows XP	XP

>>>> Врезка внимание!

FILE Record, INDEX Record, RCRD Record или RSTR Record искажены последовательностями обновления и в обязательном порядке должны быть восстановлены перед их использованием, в противном случае вместо актуальных данных вы получите мусор!

Долгое время главным козырем противников

Долгое время главным козырем противников NTFS был следующий аргумент – чем вы будете ее восстанавливать, если она умрет? А мрет она, как показывает практика, достаточно часто. При всей своей надежности, NTFS не застрахована от потрясений. Ошибки оператора, вирусы, сбои питания, зависания ОС, дефекты поверхности, отказ электроники… С каждым днем человечество все сильнее и сильнее становится зависимо от компьютеров, объемы жестких дисков стремительно растут, а вместе с тем растет и ценность содержащихся на них данных, потеря которых зачастую невосполнима.
Спрос рождает предложение и на рынке как грибы после дождя вылупляются фирмы, специализирующиеся на восстановлении данных, однако, по-настоящему хороших специалистов можно встретить только в двух, ну от силы в трех из них, а все остальные лишь создают видимость кипучей деятельности, выставляя астрономические счета при довольно посредственном качестве восстановления. Но время кустарей уже ушло. Рабочая атмосфера изменилась. Хакеры разобрались со строением NTFS и документировали ее ключевые структуры. Начал формироваться достойный инструментарий для ручного восстановления. Наконец, за минувшее время накопился огромный опыт по борьбе за спасение данных, частью которого автор и хочет поделиться с читателями.

б) хакерская документация от коллектива "Linux-NTFS Project" (http://linux-ntfs.sourceforge.net/), чьим хобби долгое время была разработка независимого NTFS-драйвера для OS Linux, однако, сейчас энтузиазм команды начал стремительно угасать. Это выдающееся творение, подробно описывающее все ключевые структуры файловой системы (естественно, на английском языке), отнюдь не заменяет книгу Хелен, а лишь расширяет ее! Разобраться в NTFS-project'e без знаний NTFS очень и очень непросто!
в) документация от Active Data Recovery Software на утилиту Active Uneraser, бесплатную копию которой можно найти на сайте www.NTFS.com. Это своеобразный синтез книги Хелен и Linux-NTFS Project, описывающий важнейшие структуры данных и обходящий стороной все вопросы, которые только можно обойти. Здесь же можно найти до предела выхолощенное изложение методики восстановления данных. В общем, если не найдете Хелен, скачайте демонстрационную версию Active Uneraser и воспользуйтесь прилагаемой к нею документацией (внимание! Active Uneraser поставляется в двух вариантах – образе FDD и образе CD, документация присутствует только на последнем из них).
г) контекстная помощь на Disk Explorer так же содержит достаточно подробное описание файловой системы, однако, на редкость бестолково организованное. Для упрощения навигации по тексту рекомендуется декомпилировать chm-файл в обычный текст, вручную перегнав его в MS Word, pdf или любой другой симпатичный вам формат.
Наконец, вы можете воспользоваться этой статьей ### ;) Однако, наличие документации Linux-NTFS Project все же очень желательно, поскольку мы будем часто ссылаться на нее.

Выбор носителей для копирования

Времена, когда восстанавливаемый винчестер было можно скопировать на пару пачек дискет, давно прошли и теперь процедура спасения данных значительно усложнилась. Пишущие приводы (особенно DVD)– хороший выбор и пара пачек болванок вмещает в себя жесткий диск любой разумной емкости, однако достойных программ прожига под MS-DOS нет и по-видимому уже и не будет. Существующие утилиты (включая их консольные разновидности!) требуют для своего запуска Windows PE/Bart PE, который не в состоянии монтировать разрушенные NTFS-диски (на некоторых из них NTFS-драйвер просто виснет или уходит в голубой экран).

Штатная же консоль восстановления, NTFSDOS Proffessional и Active@ Data Recovery Boot Disk поддерживают только дискеты и IDE-накопители, причем демонстрационные версии двух последних требуют, чтобы диск-приемник был размечены под FAT16/32, а его максимальный объем не превышал 8 Гбайт. Если же вам необходимо восстановить диск большего объема – последовательно копируйте его на несколько жестких дисков. Согласен, это достаточно дорогое удовольствие, но дешевых решений в деле восстановления данных не бывает.

К тому же, имя файла

Доступны все UNICOE-символы (без учета регистра), за исключением следующего набора: '"' (кавычки), '*' (звездочка), '/' (прямой слеш), ':' (двоеточие), '<' (знак меньше), '>' (знак больше), '?' (вопросительный знак), '\' (обратный слеш), '|' (символ конвейера). К тому же, имя файла не может заканчиваться на точку или пробел. Максимально допустимая длина имени составляет 255 символов.

Загрузочная дискета

Средства восстановления и диагностики, расположенные на основном жестком диске, годятся разве что для обучения, а для реальной работы они бесполезны. Даже если сбой окажется не настольно серьезным, чтобы воспрепятствовать загрузке Windows, попытка "лечения" диска в многозадачной среде носит весьма непредсказуемый характер. Записывая что-либо на диск в обход драйвера файловой системы вы здорово рискуете. Допустим, вы восстанавливаете удаленный файл, обновляя MFT (Master File Table – святая святых файловой системы NTFS), а в это время система создает/удаляет другой файл, обращаясь к тому же самому сектору, что и вы. Ну и что произойдет в результате? Правильно – файл, а, возможно, и весь дисковый том, умрет окончательно. К тому же система блокирует активные исполняемые файлы и файлы данных, что делает невозможным их восстановление даже при наличии архивной копии. Про борьбу с вирусами лучше вообще не говорить. Многие вирусы, обосновавшись в системе, блокируют запуск антивирусных программ или умело скрываются от них, не давая себя удалить или обнаружить. Если же в результате сбоя перестала загружаться Windows, вы вообще остаетесь ни с чем…

Главное преимущество FAT16/32 по сравнению с NTFS это, бесспорно, возможность загрузки с системной дискеты. MS-DOS 7.0 поддерживает длинные имена, позволяя скопировать с восстанавливаемого диска все файлы, которые только доступны штатному драйверу операционной системы. Но с NTFS такой номер уже не пройдет! Однако, никто не запрещает нам подключить восстанавливаемый диск "вторым" к системе с работоспособной NT. Для этого даже не обязательно иметь два компьютера. Просто подключите к своему компьютеру еще один винчестер, установите на него NT и наслаждайтесь жизнью. При этом следует учитывать, что информация о программных RAID'ах, созданных Windows NT 4.0 или более ранними версиями, содержится в реестре и потому при переносе диска на другую систему оказывается недоступна. Динамические диски, появившиеся в Windows 2000, хранят свою атрибуты в фиксированных местах диска и потому не привязаны к своей родной системе. С шифрованными файлами дела обстоят не в пример хуже. Ключ шифровки хранится в недрах пользовательского профиля и на другой системе извлечение файлов оказывается невозможным. Причем, создание пользователя с таким же именем/паролем не решает проблемы, т. к. ключ генерируется системой случайным образом и не может быть воспроизведен. Ничего не остается, как действовать тупым перебором.

Некоторые типы разрушений файловой системы способы завешивать оригинальный NTFS-драйвер или выбрасывать синий экран смерти, что создает серьезные проблемы (чтобы восстановить диск, мы должны запустить определенный инструментарий, а чтобы запустить инструментарий, нам надо загрузить Windows, а вот это мы как раз сделать и не можем!). Попробуйте подключить такой диск к системе, не поддерживающий NTFS (например, Windows 98 или MS-DOS), естественно выбранные вами утилиты восстановления должны быть совместимы с ней. Или – как вариант – натравите на такой диск LINUIX. Драйвер LINIX'а игнорирует вспомогательные структуры файловой системы (такие, например, как файл транзакций) и потому успешно монтирует диск даже когда в них содержится сплошной мусор.

Благодаря усилиям Марка Руссиновича, создавшего замечательную утилиту NTFSDOS Professional, мы может работать с NTFS-разделами в среде Windows 9x/MS-DOS. Однако, это отнюдь не самостоятельный драйвер, а всего лишь обертка вокруг штатного NTFS.SYS, эмулирующая необходимое окружение и диспетчеризующая файловые запросы. С одной стороны это хорошо тем, что мы имеем полноценную поддержку NTFS, на 100% совместимую с нашей версией операционной системы (NTFS.SYS извлекается как раз оттуда), в то время как драйвера сторонних производителей (и в частности драйвер LINIX'а) реально работают лишь на чтение, да и то кое-как (потоки и прочие "вкусности" NTFS начисто игнорируются). С другой стороны, если порушенный диск завешивает NTFS.SYS, он завесит и Руссиновича! Однако, с такими проблемами приходится сталкиваться не так уж и часто, поэтому полезность этой утилиты воистину неоценима. Демонстрационная копия NTFSDOS Profrssional, доступная для бесплатного скачивания (http://www.sysinternals.com/files/NTFSProR.exe), поддерживает лишь чтение NTFS-дисков, а за возможность записи приходится платить (несите свои денежки на http://www.winternals.com – платный вариант www.sysitnernals.com).. Впрочем, поскольку NTSFDOS Professional всего лишь обертка, после небольшой доработки напильником она с готовностью соглашается и читать, и писать. (Внимание! Никто не говорит о взломе! Мы ничего не ломаем! Напротив, мы создаем, наращивая функциональность программы!). Кратко об установке и сопутствующих проблемах. Для начала вам потребуется создать системную дискету, что легче всего осуществить средствами Windows 98. Русская версия MS-DOS даже в минимальном комплекте поставки (io.sys + command.com) занимает намного больше места, чем рассчитывал Руссинович и NTFSDOS Professional на стандартную 3" дискету уже не вмещается. Поэтому, приходится устанавливать NTFSDOS Professional на чистую диску (точнее говоря, инсталлятор создает таких дисков два – на первый помещает NTFS-драйвер, а на второй – chkdsk.exe). Загрузившись с системной дискеты, выньте ее из дисковода (естественно, command.com должен быть предварительно скопирован на виртуальный диск), вставьте первый диск, сформированный инсталлятором и наберите в командной строке NTFSPRO.EXE.

Как вариант можно воспользоваться загрузочным диском от компании Active@Data Recovery Software

(http://download2.lsoft.net/NtfsFloppySetup.exe) или загрузочным CD-ROM диском от нее же (http://download2.lsoft.net/boot-cd-iso.zip). Центральным звеном каждого из них является независимый NTFS-драйвер, работающий из под MS-DOS и монтирующий NTFS тома даже при полном разрушении вспомогательных файловых структур и серьезном повреждении таблицы MFT и полном разрушении корневого каталога. Драйвер самостоятельно сканирует диск в поисках уцелевших записей в MFT, показывая в том числе и удаленные файлы, предлагая их восстановить. Естественно, возможность записи на диск реализована только в коммерческой версии, а демонстрационная позволяет лишь скопировать файлы на внешний носитель (жесткий диск, размеченный под FAT, или дискету). Динамические диски, к сожалению, не поддерживаются. Помимо этого в комплект входит утилита для создания/восстановления образом диска, средство избавления диска от данных (полезно когда вы сдаете диск с конфиденциальными данными назад продавцу), программу для работы с патрициями[1]

(восстановление разрушенных таблиц разделов и их заблаговременная архивация), и автономный энурез – утилиту unerase для NTFS.

Если приобретение второго жесткого диска вам не по карману, а возможности MS-DOS загрузчиков вас не устаивают, воспользуйтесь другой утилитой Марка Руссиновичка – ERD Commander'ом, позволяющим запускать усеченную версию Windows с дискет (5 штук) или CD-диска. В настоящее время ERD Commander распространяется только на коммерческом основании, хотя в сети до сих пор можно найти предыдущие, бесплатные версии, хотя их функциональные возможности весьма ограничены. В частности, опробованный мной EDR Commander 2000 вызывал смесь разочарования с удивлением. Во-первых, он забросил на дискету многопроцессорное ядро (а у меня однопроцессорная машина!). Как следствие, при загрузке с дискеты Windows не нашла нужного ядра и умерла еще в зачатье. Пришлось менять ядро вручную. Затем всплыли и другие ошибки инсталлятора и пришлось немало попотеть, прежде чем Windows все-таки загрузилась. Подготовленный инсталлятором образ CD-ROM'а так же был в сильно разобранном стоянии – просто папка с файлами и bootsector.bin, который еще не каждой утилитой прожжешь (я пользовался CDRTOOLS, так же подходит и CDRWIN, а вот популярный Нерон, сжигающий Рим, для этой цели увы, не пригоден). Тем не менее, ERD Commander стоит всех мучений! С его помощью вы можете: менять администраторский пароль в системе, редактировать реестр упавшей системы, управлять сервисами и драйверами, восстанавливать удаленные файлы, копировать и модифицировать любые системные и пользовательские файлы (в том числе и по сети), редактировать таблицу разделов и управлять динамическими дисками, сравнивать файлы упавшей и рабочей системы, производить откат системы в рабочее состояние и многое-многое другое. К сожалению, непосредственными средствами для восстановления разрушенного диска ERD Commander не располагает и в основном он применим для реанимации операционной системы (правда, из под ERD Commander'а вы можете вызвать дискового доктора или любую другую Windows-утилиту, в таком случае никакого смысла в его приобретении нет – второй винчестер будет дешевле).

Начиная с Windows 2000, Microsoft наконец-то включила в операционную систему некоторую пародию на загрузчик, способную стартовать с CD-ROM и поддерживающую NTFS. Называется эта штука Консоль Восстановления

или по-английски Recovery Console. Это действительно консоль, ничего не знающая о GUI и способная запускать только консольные приложения (типа chkdsk.exe и подобных им). Для ее активации загрузитесь с дистрибутивного CD-ROM и сделайте вид, что хотите переустановить систему, но на определенном этапе установки нажмите <R> для вызова консоли восстановления. Вас запросят пароль администратора (если вы его забыли или системный реестр поврежден войти в консоль не удастся!), при успешной регистрации запуститься командный интерпретатор, позволяющий (теоретически!) скопировать уцелевшие файлы на другой диск. Практически же по умолчанию доступа только папка WINNT, причем копирование на съемные носители запрещено. Хорошенькое начало! Вам нужна WINNT? Личные документы намного нужнее! К счастью, доступ можно разблокировать. Для этого необходимо присвоить системным переменным AllowAllPaths и AllowRemovableMedia значение true ("SET AllowAllPaths = true", "SET AllowRemovableMedia = true"), или локальных параметрах безопасности" (папка Администрирование в Панели Управления) заблаговременно найти пункт "Консоль восстановления: разрешить копирование дискет и доступ ко всем папкам" и перевести рубильник во включенное состояние. Смысл этой защиты не совсем понятен. Простые пользователи до консоли восстановления все равно не дотянуться, а профессионалов подобные манипуляции ужасно раздражают. Находясь в консоли восстановления вы можете: запускать chkdsk[2], создавать и удалять разделы на жестком диске, перезаписывать главную запись и boot-record, форматировать логические диски, управлять службами и драйверами, удалять/копировать/переименовывать/изменять атрибуты файлов (включая те, что блокируются при запуске системы), а так же выполнять другие сервисные операции. При желании вы можете запускать и свои собственные консольные приложения, при условии, что они не используют никаких динамических библиотек за исключением NTDLL.DLL, однако, технику их создания мы обсудим как ни будь в другой раз, т. к. это очень обширный вопрос.

В Windows XP идея консоли восстановления получила дальнейшее развитие, в конце концов вылившееся в Windows PE. Это – слегка усеченная версия Windows XP, способная грузиться с CD-ROM и запускать GUI-приложения. Фактически она полностью заменят собой "второй" жесткий диск и для восстановления системы теперь не требуется никакого дополнительного оборудования! Несмотря на то, что легальная версия Windows PE в широкую продажу так и не поступала (Microsoft предоставляет ее только разработчикам оборудования, сервисным специалистам и прочим своим корешам), в России копию оригинального диска Windows PE можно найти в каждом ларьке. Пиратство пиратством, но то, что спрос рождает предложение – факт, а загружать Windows с диска требуется многим. Если же вы связаны лицензионными ограничениями, диктуемыми уставом вашей фирмы, воспользуйтесь Bart's PE Builder'ом. Эта бесплатно распространяемая утилита (http://www.danilpremgi.com/nu2/pebuilder3032.zip) вытащит с дистрьбютивного диска обыкновенной Windows все необходимые файлы и автоматически сформирует iso-образ загрузочного CD. Прожигаете его на болванку и все! При желании вы можете помещать на CD и свои собственные утилиты, формируя приличную аптечку для восстановления умерших дисков и размещающуюся на 3" CR-R/RW, свободно умещающимся в нагрудном кармане. И не зачем таскать эти жуткие стопки дискет или страшно сказать – отдельный винчестер. К слову сказать, к Bart's PE Builder'у выпущено множество плагинов, представляющих собой программы, адоптированные для запуска с CD. Среди них есть и утилиты восстановления данных, и дисковые редакторы, и даже Nero Brining Rom. Большую коллекцию плагинов можно найти на домашней страничке Bart'а – http://www.nu2.nu/pebuilder/ здесь же вы найдете и краткое руководство по работе с PE Builder'ом. Официально PE Builder поддерживает Windows 2000, Windows XP и Windows 2003, однако, при ближайшем рассмотрении выясняется что ему как минимум нужен Windows 2000 с интегрированным SP1, зато создание диска на базе Windows 2003 прошло успешно (использовался CD-ROM с 180-дневной версией Windows 200 Server, бесплатно распространяемый компаний Microsoft).

Загрузочный сектор– базовые концепции

Первый сектор логического диска носит название загрузочного

(boot). Он содержит самозагрузочный код (bootstrap code) и важнейшие сведения о геометрии диска без которых раздел просто не будет смонтирован! Структура boot-сектора определяется архитектурными особенностями конкретной файловой системы, в частности NTFS boot sector выглядит так:

смещение	размер	назначение
0x00	3 bytes	инструкция перехода
0x03	8 байт	OEM ID – идентификатор
0x0B	25 bytes	BPB
0x24	48 bytes	Extended BPB
0x54	426 bytes	Bootstrap Code
0x01FE	WORD	55 AA

Загрузочный сектор– техника восстановления

Осознавая значимость загрузочного сектора, Windows NT при форматировании диска создает его зеркальную копию (правда, только на NTFS разделах). Windows NT 4.0 располагает ее посередине логического диска, а Windows 2000 – в последнем секторе раздела. Если partition table цела, просто перейдите в начало следующего раздела и отступите на сектор назад (Windows 2000) или поделите количество секторов логического диска пополам (с округлением в нижнюю сторону) и скажите редактору диска "GO" (Windows NT 4.0).

Если же таблица разделов разрушена, найти копию сектора можно глобальным поиском (ищите строку "NTFS" по смещению 3 от начала сектора). Поскольку, положение копии фиксировано и отсчитывается от начала логического диска, мы можем с абсолютной уверенностью определить границы раздела. Допустим, копия boot'a найдена в секторе 1289724, а поле NumberSectors содержит значение 12289661. Тогда конечный сектор раздела равен 1289724, а стартовый: 1289724 – 12289661 == 63. Поскольку, загрузочный сектор расположен на расстоянии одной головки от partition table, что соответствует SectorPerTrack секторам, мы можем восстановить и ее.

В отсутствии копий, boot сектор приходится реконструировать вручную. Это легко. В поле идентификатора производителя заносится строка "NTFS " (без кавычек, но с четырьмя пробелами на конце). Кол-во секторов в треке и число головок заполняются исходя из текущей геометрии диска. Кол-во скрытых секторов (т. е. секторов расположенных между началом раздела и boot-сектором) равно числу головок. Общее количество секторов в разделе вычисляется на основании его размера (если точный раздел не известен, берите значение с запасом).

Кол-во секторов в кластере определить сложнее (особенно, если диск отформатирован со значением, отличным от принятого по умолчанию). Но ситуация вовсе не безнадежна. Последовательно сканируя файловые записи в MFT, найдите файл с наперед известной сигнатурой. Пусть для определенности это будет NTOSKRNL.EXE. Откройте его аутентичную копию в HEX-редакторе, найдите уникальную последовательность, гарантировано не встречающуюся ни в каких других файлах и расположенную в пределах первых 512 байт от его начала, после чего найдите ее глобальным поиском на диске. Начальный номер кластера вам известен (он содержится в MFT), логический номер сектора тоже (его нашел дисковый редактор). Теперь остается лишь соотнести эти две величины между собой. Естественно, если дисковый ректор найдет удаленную копию NTOSKRNL.EXE (или на диске будут присутствовать несколько файлов NTOSKRNL.EXE), данный метод даст осечку, поэтому полученный результат необходимо уточнить на других файлах.

Логический номер первого кластера MFT равен первому кластеру, в начале которого встретилась строка "FILE*" (конечно, при том условии, что MFT не был перемещен). Штатно Windows выделяет под MFT 10% от емкости раздела, помещая зеркало в середину. Кроме того, ссылка на зеркало присутствует и в самом MFT. Если же он разрушен, переместитесь в середину диска, немного отступите назад и повторите глобальный поиск строки "FILE*" (только, смотрите, не вылетите в соседний раздел!). Первое же найденное вхождение с высокой степенью вероятности и будет зеркалом.

Количество кластеров на сегмент обычно равно F6h, а кол-во кластеров на блок индексов – 01h. Других значений мне встречать не доводилось. Серийный номер тома может быть так же любым – он ни на что не влияет.

Для восстановления отсутствующего (искаженного) bootstrap code загрузите консоль восстановления и отдайте команду FIXBOOT.

в восстановлении данных нет ничего

Как видно, в восстановлении данных нет ничего мифического и для устранения большинства типов разрушений не требуется никакой квалификации. Если же некоторые места вам не понятны, перечитайте эту статью с дисковым редактором в руках. До сих пор мы говорили о достаточно простых и хорошо известных вещах. Теперь, как следует раскачавшись и освоившись с основными понятиями мы может отправляться в самые дебри NTFS, восстановлению структур которой посвящена следующая статья этого цикла.