Литмир - Электронная Библиотека
Содержание  
A
A

Исправление ошибок в атрибуте 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 легко распознает даже переупорядоченные блоки, поэтому высокая степень фрагментации ему не помеха.

49
{"b":"837815","o":1}