понедельник, 11 мая 2009 г.

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

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

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

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

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

Надежность NTFS – это одно, а ошибочно удаленные файлы – совсем другое. Файловая система, даже такая мощная как NTFS, бессильна защитить пользователя от себя самого. Но вот предусмотреть "откат" последних выполненных действий она вполне может (тем более, что транзакции и журналирование в NTFS уже реализованы). До совершенства остается всего лишь шаг. Увы! Microsoft топчется на месте, все никак не решаясь его сделать (задел, оставленных для будущих версий?) "Защита" от непреднамеренного удаления реализована исключительно на интерфейсном уровне, а это не только неудобно, но и ненадежно.

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

внутри FILE_DISPOSITION_INFORMATION

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

 

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

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

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

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

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

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

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

 

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

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

Комментариев нет:

Отправить комментарий