НЕСЛУЧАЙНО CUDA ИДЕМ? phpMyAdmin - Xakep Online

unixoid
СТРУКТУРА КАТАЛОГА В EXT2/3
INFO
info
• Для исследования
файловой системы
ext2 необязательно
использовать
стандартную утилиту
debugfs. Есть более
дружественная
и наглядная
альтернатива под
названием LDE
(Linux Disk Editor, lde.
sourceforge.net).
• Файловая система
ext2 была спроектирована
по образу
и подобию UFS (Unix
File System), поэтому
ты легко вникнешь
в тему, если захочешь
разобраться в особенностях
восстановления
файлов
в BSD-системах.
• Существует
множество утилит,
автоматизирующих
процесс восстановления
данных
в файловых системах
ext2 и ext3, наиболее
функциональные из
которых: TestDisk
(www.cgsecurity.
org/wiki/TestDisk),
undelete (www.stud.
tu-ilmenau.de/~mojo/
undelete.html) и
sleuthkit (www.
sleuthkit.org).
084
что дает право другим файлам использовать их для хранения
своей информации. Освобождается и сам inode, но опасность
его повторного использования другим файлом очень
низка в силу большого резерва файловых дескрипторов,
которые будут задействованы в первую очередь. Получается,
что для восстановления удаленного файла в файловой
системе ext2 достаточно узнать номер его inode, прочитать
и распутать вереницу массивов ссылок на блоки данных, а
затем собрать из них файл!
С файловой системой ext3 все намного сложнее: ее драйвер
очищает массив ссылок на блоки (i_block), так что файл
придется собирать по кусочкам, разыскивая блоки по всей
файловой системе.
В СТРАНЕ МЕРТВЫХ
Чтобы избежать перезаписи блоков удаленного файла, восстановление
следует начать с немедленного размонтирования
раздела. Если же файл находился на корневом разделе,
лучшее средство — кнопка RESET на системном блоке и
последующая загрузка с LiveCD.
Для низкоуровневой навигации по файловой системе
необязательно использовать шестнадцатеричный редактор,
существует несколько утилит, которые облегчают этот процесс.
Одна из них — стандартная команда debugfs из пакета
e2fsprogs.
Запусти ее с указанием раздела, содержащего подопытную
файловую систему:
$ debugfs /dev/sda1
Откроется командная строка, которая принимает множество
команд. Набери help, чтобы увидеть их. Наиболее интересные
для нас команды: lsdel, stat, cat и dump. Команда lsdel
показывает все удаленные inode. Выполни ее:
debugfs: lsdel
Скорее всего, список будет очень длинным, поэтому лучше
сразу перенаправить его в файл:
$ echo lsdel | debugfs /dev/sda1 > /tmp/lsdel.
out
Открой полученный файл и попытайся найти разыскиваемого
по времени удаления, размеру, владельцу и другим
данным. Запомни номер его inode и выполни команду stat в
командной строке debugfs:
debugfs: stat
На экране появится вся информация об inode (номер,
тип, владелец, время создания и удаления и пр.). В
конце вывода будет присутствовать информация о
блоках, занимаемых файлом на диске, и их количество.
На основе этих данных можно восстановить любой
файл, воспользовавшись командой dd в качестве
инструмента. Но есть более простой способ. Команда
dump делает снимок всех блоков, принадлежащих
указанному inode, и записывает их в указанный файл.
Попробуй:
debugfs: dump -p /tmp/âîññòàíîâëåííûé_ôàéë
Ключ ‘-p’ сохраняет за файлом прежние права доступа, владельца
и группу. Имя файла придется подобрать по памяти,
оно хранилось в каталоге и было затерто во время удаления.
Если ты ищешь текстовый файл, то для полной уверенности
лучше сначала выполни команду cat над inode, которая
выведет содержимое файла прямо на экран:
debugfs: cat
Чтобы идентифицировать файл после его восстановления,
можешь применить утилиты file и strings. Первая покажет
тип файла, а вторая выведет на экран все читаемые строки,
которые он содержит.
Для восстановления утраченных файлов необязательно
делать их дамп в существующую файловую систему, — можно
изменить саму inode-таблицу. Сделать это просто. Открываем
дисковый раздел (или его снимок) в режиме записи:
# debugfs -w /dev/sda1
Находим описанным выше способом inode удаленного файла
и открываем его на редактирование:
debugfs: mi
Команда mi расшифровывается как «modify inode» и предназначена
для ручного редактирования inode. Она выводит
на экран все поля inode и их текущие значения, заключенные
в квадратные скобки. Курсор будет останавливаться
у каждого поля, ожидая ввода нового значения, которое
можно пропустить, нажав . Нас интересует только два
поля: время удаления (Deletion time) и количество ссылок
(Link count). Первое следует обнулить, а второму присвоить
значение 1. Так мы вернем мертвый файл к жизни, но введем
файловую систему в скомпрометированное состояние: файл
есть, но найти его невозможно (запись каталога, содержащая
его имя и ссылку на inode, уже затерта). С точки зрения
файловой системы это ошибка, которая дает нам два варианта
последующих действий.
Мы можем запустить fsck, который найдет несоответствия в
файловой системе и исправит их, поместив наших призраков
в каталог lost+found:
# e2fsck -f /dev/sda1
Или же воспользоваться методом прямого вмешательства:
создать жесткую ссылку на файл, используя команду link
утилиты debugfs:
debugfs: link âîññòàíîâëåííûé_ôàéë
Восстановленный файл появится в текущем каталоге. Однако
команду e2fsck придется запустить и в этом случае, потому
как закрепленные за файлом блоки до сих пор помечены как
неиспользуемые.
КАК БЫТЬ С EXT3?
Как мы уже упоминали, Linux-драйвер ext3 использует
другой механизм разлинковки. Он затирает всю таблицу
соответствия в inode, делая процесс восстановления
данных чрезвычайно трудным, если не сказать невозможным.
Но попробуем мыслить логически. Файл представляет
собой последовательность блоков определенного
размера, разбросанных по всему жесткому диску. У
каждого типа файла есть набор признаков, по которым
XÀÊÅÐ 07 /127/ 09