Текст книги "Восстановление данных. Практическое руководство"
Автор книги: Крис Касперски
Жанры:
Компьютерное "железо"
,сообщить о нарушении
Текущая страница: 13 (всего у книги 26 страниц)
Начнем с простейшего. Файл только что удален, и принадлежащая ему файловая запись еще не затерта. Как найти его на диске? Существует два способа – "теоретический" и "практический". Теоретический метод исключительно надежен, но требует дополнительных операций, выполнения которых можно избежать, приняв ряд практических допущений.
Теоретически грамотный и правильный подход состоит в следующем. Извлекаем из загрузочного сектора указатель на 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 индексах.
0 КБ в поврежденных секторах.
7894 КБ используется системой.
7392 КБ занято под файл журнала.
1060372 КБ свободно на диске.
Размер кластера: 2048 байт.
Всего кластеров на диске: 534145.
530186 кластеров на диске.
Рассмотрим более сложный случай восстановления, а именно – случай, когда файловая запись уже затерта. Если удаленный файл был резидентным (хранил свое тело в MFT), то восстанавливать уже нечего. Даже если на ранее занимаемом им месте создан нерезидентный файл (а файловая запись нерезидентного файла заканчивается там, где начинается резидентное тело), операционная система заботливо заполнит оставшийся "хвост" нулями, и для восстановления оригинального содержимого придется прибегнуть к дорогостоящему оборудованию, читающему поверхность жесткого диска на физическом уровне.
С нерезидентными файлами, хранящими свое тело вне MFT, ситуация обстоит не так плачевно, хотя и здесь проблем тоже хватает. Порядок размещения файла на диске хранится в списке отрезков (run-list) внутри файловой записи в MFT. При этом, поскольку файловая запись уже затерта, возможен лишь контекстный поиск по содержимому. Запускаем дисковый редактор, вводим последовательность, заведомо содержащуюся в удаленном файле, но не встречающуюся во всех остальных, и даем редактору команду начать поиск. Для ускорения поиска можно искать только в свободном дисковом пространстве (за это отвечает файл /$BITMAP). Известные мне редакторы напрасно пренебрегают этой возможностью, однако утилиту "продвинутого" поиска несложно написать и самостоятельно.
Восстановление нефрагментированных файлов осуществляется элементарно. Достаточно просто выделить группу секторов и записать ее содержимое на диск.
Внимание!
Повторюсь еще раз – ни в коем случае не записывайте файлы не на сам восстанавливаемый том!
Единственная проблема заключается в определении оригинальной длины. Некоторые типы файлов допускают присутствие "мусора" в своем хвосте. В этом случае можно следовать правилу, гласящему, что перебор лучше недобора. Однако это справедливо не для всех файлов! Если конец файла не удается определить визуально (например, pdf-файлы завершаются сигнатурой %%EOF), проанализируйте заголовок файла. Как правило, наряду с прочей полезной информацией там присутствует и размер файла. В данном случае все зависит от структуры конкретного файла, и универсальных рекомендаций дать невозможно.
Если восстанавливаемый файл фрагментирован, то ситуация осложняется. По правде говоря, она практически безнадежна, поскольку, чтобы собрать разрозненные цепочки кластеров воедино, необходимо хорошо знать содержимое удаленного файла. В этом смысле NTFS восстанавливается намного хуже, чем FAT. Последовательность фрагментов файла, хранящаяся в FAT в виде однонаправленного списка, очень живуча. Если список не поврежден, достаточно лишь найти его первый элемент (а сделать это проще простого, поскольку он будет указывать на заголовок файла с вполне предсказуемым содержимым). Даже если список "разрубить" на несколько частей, они продолжат жить собственной жизнью, и останется лишь подобрать комбинацию, в которой их необходимо склеить воедино. Список гибнет лишь при полном затирании FAT, что случается, прямо скажем, не часто. В NTFS же порядок фрагментов файла хранится в крохотных списках отрезков, и их гибель – обычное дело, после чего мы остаемся один на один с миллионом беспорядочно разбросанных кластеров. С текстовыми файлами еще можно работать, но что делать, если файл представлял собой электронную таблицу, графическое изображение или архив? Без знания стратегии выделения дискового пространства восстановить такой файл невозможно. Порядок, в котором драйвер файловой системы находит подходящие свободные фрагменты, не предопределен. Он варьируется в зависимости от множества обстоятельств, однако некоторые закономерности в нем все же присутствуют.
В ходе анализа списков отрезков сильно фрагментированных дисков мне удалось установить следующие закономерности. Сначала заполняются самые большие "дыры", причем заполнение происходит в направлении от конца зоны MFT к концу диска. Затем драйвер файловой системы возвращается назад и начинает заполнять "дыры" поменьше. Так продолжается до тех пор, пока файл не оказывается на диске целиком. В последнюю очередь заполняются "дыры" размером в один кластер. Просматривая карту диска, представленную файлом /$BITMAP, мы можем в точности восстановить порядок размещения фрагментов удаленного файла, наскоро собрав их воедино. Во всяком случае, теоретически такая возможность существует. На практике же на этом пути нас ждут коварные препятствия. Дело в том, что с момента создания восстанавливаемого файла карта свободного дискового пространства могла радикально измениться. Всякая операция удаления файлов высвобождает одну или несколько "дыр", хаотично перемешивающихся с "дырами" восстанавливаемого файла. Как этому противостоять? Сканируем MFT в поисках записей, помеченных как удаленные, но еще не затертых. Декодируем списки отрезков и вычеркиваем соответствующие им фрагменты из списка кандидатов на восстановление. Это существенно сужает круг поиска, хотя количество комбинаций, в которые можно собрать фрагментированный файл, по– прежнему остается велико. Но это не самое главное.
Самое "интересное" начинается, когда на диск одновременно записываются несколько файлов (например, скачиваемых из Интернета) или когда некий файл постепенно увеличивает свой размер (это происходит с документами Word при наборе текста), и одновременно с этим на диск записываются другие файлы. Когда к существующему файлу дописывается крошечная порция данных, файловая система находит наименьшую "дыру", затем следующую наименьшую "дыру" и т.д., вплоть до тех пор, пока маленькие "дыры" не исчерпаются. Когда это происходит, наступает черед "дыр" большего размера. В результате файл сильно фрагментируется. Кроме того, файл заполняется не от больших дыр к меньшим, а наоборот (т.е. происходит инверсия стратегии размещения). Таким образом, маленькие фрагменты одного файла перемешиваются с маленькими фрагментами других файлов.
Хуже всего поддаются восстановлению документы, созданные в Microsoft Office. Происходит это потому что приложение создает большое количество резервных копий редактируемого файла, как в текущем каталоге, так и в каталоге %TEMP%. Разобраться с тем, какой фрагмент какому файлу принадлежит, очень нелегко!
Проще всего восстанавливать ZIP-архивы. Для этого вам даже не потребуется запускать дисковый редактор. Откройте временный файл на запись, сделайте seek на размер свободного дискового пространства, закройте файл. А теперь обработайте его утилитой pkzipfix.exe (или запустите стандартный pkzip.exe с ключом Fix). В "исправленном" файле волшебным образом появятся все уцелевшие ZIP-архивы! Внутренняя структура ZIP-архива такова, что pkzipfix легко распознает даже переупорядоченные блоки, поэтому высокая степень фрагментации ему не помеха.
Дефрагментация тоже происходит интересно. Стандартный API дефрагментации в силу малопонятных ограничений оперирует не единичными кластерами, а блоками! Минимальный размер блока составляет 16 кластеров, причем начало блока должно быть кратно 16 кластерам в файле! Количество мелких "дыр" после дефрагментации только возрастает, а непрерывных областей свободного пространства практически совсем не остается.
Не забывайте, что перемещать что-либо внутрь зоны MFT тоже нельзя. Наверняка вы знакомы с системным сообщением примерно следующего вида:
На томе С: свободно 17%, но только 5% доступно для использования
дефрагментатора диска. Для эффективной работы дефрагментатор требует
по крайней мере 15% доступного свободного места.
"Недоступное" для дефрагментатора пространство находится внутри зоны MFT, потому что, как вы помните, при форматировании диска для хранения файла $MFT резервируется 12,5% от емкости тома. Затем, по мере исчерпания дискового пространства, файл $MFT усекается наполовину, а освободившееся за счет этого дисковое пространство отдается для хранения пользовательских файлов. Иначе говоря, для гарантированной работы дефрагментатора ему нужно 10% + 15% == 25% свободного дискового пространства. Не слишком ли высока эта плата за дефрагментацию? Если же у вас свободно свыше 25%, настоятельно рекомендуется создать на диске временный файл и выполнить seek, чтобы заполнить все более или менее крупные "дыры", что не позволит дефрагментатору их изуродовать. Разумеется, после дефрагментации этот файл нужно удалить. К счастью, на сжатые файлы ограничение на минимальный размер блока в 16 кластеров не распространяется, поэтому мелкие файлы очень выгодно держать в сжатом состоянии, так как это существенно уменьшает фрагментацию тома. Чаще дефрагментируйте свой диск! Это не только увеличит быстродействие, но и упростит восстановление удаленных файлов с затертой файловой записью.
Вообще говоря, восстановление файлов – операция несложная, но нудная и кропотливая. Если по долгу службы или в силу иных обстоятельств вам приходится заниматься восстановлением постоянно, то этот процесс можно "автоматизировать", написав несколько простых утилит. Чтобы получить доступ к логическому разделу в Windows NT, достаточно открыть одноименное устройство с помощью функции CreateFile("\.X:", GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0), где X: – буквенное обозначение логического диска. Более подробную информацию по данному вопросу можно найти в документации Platform SDK.
Не думайте, что все уже написано задолго до вас! Утилит, пригодных для профессионального восстановления данных, под NTFS до сих пор нет. Во всяком случае, их нет в открытой продаже. Имеющиеся же средства восстановления страдают массой нелепых ограничений. Например, они не могут ограничить диапазон секторного поиска только свободным или только занятым пространством. Так что дерзайте!
Существуют, по меньшей мере, две методики исследования стратегии выделения дискового пространства: статическая и динамическая. При использовании статической методики мы просто запускаем дисковый редактор (предпочтение следует отдать DiskExplorer от Runtime Software) и анализируем списки отрезков уже существующих файлов, записанных в различное время и различными способами. Например, можно скопировать файл из одного каталога в другой или попеременно увеличивать размер нескольких файлов – стратегии выделения свободного пространства в обоих случаях будут различны (рис. 7.3). Статический подход полезен тем, что дает бесценный статистический результат для всего тома в целом. Однако этот метод позволяет определить лишь окончательный результат, но не путь, которым этот результат был достигнут.
Рис. 7.3. Статический анализ стратегии выделения дискового пространства, выполняемый при помощи DiskExplorer от Runtime Software
Утилита Diskmon.exe, разработанная Марком Руссиновичем (Mark Russinovich) и доступная для свободного скачивания на его сайте (http://www.sysinternals.com), позволяет заглянуть в "святая святых" файловой системы и увидеть, как именно она выделяет дисковое пространство для хранения файлов (рис. 7.4). Особенно интересно запускать Diskmon.exe параллельно с дефрагментатором или утилитой chkdsk, так как в этом случае все тайное сразу становится явным.
Рис. 7.4. Динамический анализ стратегии выделения дискового пространства, выполняемый при помощи Дискового Монитора Марка Руссиновича
Восстановление разделов NTFS после форматированияСовет
Если, несмотря на все усилия, восстановить удаленный файл так и не удается, попробуйте отыскать его резервную копию. Многие приложения создают такие копии, но не все афишируют их присутствие. Не стоит забывать и о файле подкачки, временных файлах, дампе памяти и других источниках, которые могут хранить фрагменты восстанавливаемого файла. Если вам повезет, можно даже найти там весь файл целиком. Даже если эти источники информации тоже уже были удалены, возможно, принадлежащие им файловые записи еще не затерты, и тогда восстановление не займет много времени.
Представьте себе, что случилось самое страшное: вы потеряли весь раздел NTFS целиком. Возможно, вы случайно отформатировали его или пережили разрушительный дисковый сбой. Где-то там остались миллиарды байт бесценных данных, теперь уже недоступных операционной системе. Как вернуть информацию к жизни? До сих пор мы рассматривали лишь незначительные дисковые сбои и легкие разрушения данных наподобие ошибочно удаленных файлов. Теперь настал черед рассмотреть восстановление после тяжелых повреждений, при которых прежнее содержимое тома становится недоступно операционной системе. Причиной этому может быть, например, непредумышленное форматирование или искажение главной файловой таблицы.
Но не падайте духом! Из любых переделок NTFS выходит с минимальными потерями, и во всех этих случаях возможно полное восстановление данных, если к делу подойти правильно.
Проще всего начать с форматирования. Для экспериментов нам потребуется утилита format.com, входящая в стандартный комплект поставки Windows NT/2000/XP, а также дисковый раздел, не содержащий никакой ценной информации.
Совет
Лучше всего проводить эксперименты на виртуальной машине – Virtual PC или VMWare, эмулирующей жесткий диск и ускоряющей процедуру форматирования в сотни раз (рис. 7.5). Ведь время – это не только деньги, но и бесцельно прожитые годы, проведенные за созерцанием индикатора прогресса.
Рис. 7.5. Форматирование виртуального диска в среде VMWare
"Живой" винчестер лучше не трогать, во всяком случае, до тех пор, пока вы не научитесь его восстанавливать. Кроме виртуальной машины, можно использовать привод ZIP (который, кстати говоря, намного надежнее оптических накопителей) и форматировать дискеты под NTFS, поскольку штатная утилита форматирования это позволяет. С обычными трехдюймовыми дискетами дело обстоит сложнее. По мнению Microsoft, их емкости недостаточно для размещения всех структур данных, хотя, простейший расчет показывает, что это утверждение не соответствует действительности, что утилита NTFSflp от Марка Руссиновича, собственно говоря, и демонстрирует. Статья "NTFS Support for Floppy Disks" (http://www.sysinternals.com/ntw2k/freeware/ntfsfloppy.shtml) подробно описывает, как обхитрить систему, заставив ее отформатировать гибкий диск под NTFS. Следует, правда, отметить, что для этого вам потребуется SoftIce.
Форматирование диска – это сложная многоступенчатая операция, намного более сложная и намного более многоступенчатая, чем это может показаться на первый взгляд. Наверняка это мнение поддержит каждый программист, который писал в свое время нестандартные утилиты для форматирования дискет. Надо отметить, что в конце восьмидесятых – начале девяностых годов прошлого века такие утилиты писали практически все. Свои исследования мы начнем с изучения тома NTFS, непредумышленно переформатированного под NTFS. Техника восстановления томов NTFS, переформатированных под FAT16/32, будет рассмотрена отдельно.
При выполнении команды format X: /U /FS:NTFS в файловой системе диска X: происходят следующие изменения (форматирование диска утилитой GUI, вызываемой из контекстного меню "проводника", осуществляется по аналогичной схеме):
1. Формируется загрузочный сектор NTFS.
2. Генерируется новый серийный номер тома, который затем записывается в загрузочный сектор по смещению 48h байт от его начала.
3. Рассчитывается новая контрольная сумма загрузочного сектора, которая затем записывается по смещению 50h от его начала (более подробная информация была приведена в гл. 5).
4. Создается новый файл $MFT, содержащий сведения обо всех файлах на диске. Как правило, он записывается поверх старого файла $MFT. Исключения из этого правила бывают, но они крайне редки. Обычно они происходят, если прежний файл $MFT был заблаговременно перемещен дефрагментатором, или если при переформатировании был назначен новый размер кластера. Во всех остальных случаях первые 24 файловых записи (FILE Record) погибают безвозвратно. Эти записи содержат непосредственно сам файл $MFT, $MFTMirr, корневой каталог, /$LogFile – файл транзакций, /$BITMAP – карту свободного пространства, /$Secure – дескрипторы безопасности, а также ряд других служебных файлов.
5. Инициализируется файл $MFT:$DATA – назначаются новая длина файла (инициализируются $MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize и $MFT:$80.LastVCN), дата и время создания и последней модификации (инициализируются $MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime и $MFT:$30.FileReadTime) и, самое главное, создается новый список отрезков (data-runs), необратимо затирающий старый. Это значит, что собирать фрагментированный файл $MFT нам придется по частям.
6. Создается новый файл /$MFT:$BITMAP, отвечающий за занятость файловых записей в MFT. При этом все старые записи помечаются как свободные, однако их фактического удаления не происходит (поле FileRecord.flags остается нетронутым), благодаря чему процедура восстановления заметно упрощается. Чаще всего $MFT:$BITMAP располагается на том же самом месте, что и старый (т.е. между загрузочным сектором и MFT), забивая прежнее содержимое нулями, однако с помощью утилиты chkdsk его можно восстановить.
7. Создается новый файл /$BITMAP, отвечающий за распределение дискового пространства (свободные и занятые кластеры). Этот файл также записывается поверх прежнего файла /$BITMAP, который, тем не менее, может быть восстановлен с помощью chkdsk.
8. Создается новый файл журнала транзакций – /$LogFile, структура которого подробно описана в документации LINUX-NTFS Project.
9. В заголовок файловой записи $MFT заносится новый LSN (LogFile Sequence Number).
10. $MFT назначается новый номер последовательности обновления (Update Sequence Number).
11. Создается новое зеркало $MFTMirr, необратимо затирающее старое (в текущих версиях файловых систем оно расположено в середине раздела NTFS).
12. Создаются новые /$Volume, /$AttrDef и другие служебные файлы, играющие сугубо вспомогательную роль и легко восстанавливаемые утилитой chkdsk. Следует отметить, что хотя /$Volume и присутствует в зеркальной копии MFT, его ценность явно преувеличена.
13. Осуществляется проверка целостности поверхности диска, и все обнаруженные плохие кластеры заносятся в файл /$BadClus.
14. Формируется новый корневой каталог.
15. Если до форматирования тома на нем присутствовал файл /System Volume Information, то он обновляется, в противном случае новый файл /System Volume Information создается только после перезагрузки.
На самом деле процесс форматирования протекает намного сложнее. Тем не менее, для восстановления данных с непреднамеренно переформатированных разделов приведенной здесь информации вполне достаточно. Углубленное обсуждение этих технических деталей требуется только программисту, разрабатывающему собственную нестандартную утилиту форматирования. Заинтересованные читатели могут самостоятельно дизассемблировать утилиту format.com (рекомендуется делать это с помощью IDA Pro).
Совет
Утилита format.com содержит лишь высокоуровневую надстройку, опирающуюся на библиотеки ifsutil.dll, untfs.dll, и непосредственно на сам драйвер файловой системы. Так что дизассемблировать придется много. Чтобы упросить себе работу, можно пронаблюдать за процессом форматирования с помощью шпионских средств (рис. 7.6), например, утилит Марка Руссиновича Filemon.exe, Diskmon.exe, бесплатные копии которых можно скачать с сайта http://www.sysinternals.com. Кроме того, не забывайте о точках останова на основные функции native API, такие как
NtFsControlFile,NtDeviceIoControlFileи т.д.
Рис. 7.6. Исследование процесса форматирования с помощью шпионских средств
