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

Применив такую конструкцию, можно попытаться восстановить все удаленные файлы.

# ./ils -rf ext2fs /dev/hda9 | awk -F '|' '($2=="f") {print $1}' | while read i; do /usr/local/tct-1.14/bin/icat /dev/hda9 $i > /tmp/deleted/$i; done

Но для сохранения данных, содержащихся во всех свободных inodes файловой системы, в отдельный файл для последующего анализа предназначена другая утилита – unrm. При ее использовании необходимо помнить две вещи: записывать результат нужно в другой раздел жесткого диска, иначе потеряете все, и в этом разделе должно быть достаточно места для сохранения данных. Например, если создать образ файловой системы размером 10 Гб, заполненной на 3 Гб при помощи утилиты dd, то он займет 10 Гб, а если при помощи unrm, то места потребуется 7 Гб (10 – 3), плюс столько же для последующего анализа. Если не доверяете системной команде dd, то, запустив unrm с опцией -e, можно создать полный образ раздела:

# ./unrm /dev/hda9 > /home/hda9_urm.res

или если извлечь неиспользованные inodes из предварительно созданного dd образа.

# ./unrm /image/system.img > /home/system_urm.res

В результате можем получить файл довольно приличных размеров, который перебрать вручную довольно хлопотное дело. И не надо. Для этого есть специально обученная утилита lazarus, анализирующая поблочно весь файл и пытающаяся определить, что за информация находится в этих блоках, а также связать разрозненные блоки между собой. При этом lazarus понимает кроме FFS, EXT2/3 и NTFS с FAT32. Утилита читает данные порциями размером 1 Кб (значение можно изменить в lazarus.cf в переменной $BLOCK_SIZE), определяет по 10 % блока, что за данные (текст, двоичные, неизвестные) находятся в нем. Если текст, то, используя регулярные выражения, пытается прочитать их, в двоичных пытается определить формат.

# ./lazarus -h /home/hda9_urm.res

XxxxxTtt...Xxxx!!!!Ttt...Xxxx!!!!!!!!!Tt.T..XXxxxx!!!!!Xx!!!!!!!!!!!!!!!!!T...T

 ttt.................!!!!!!!!!!!!!!!!!!!!!

Вывод утилиты – набор символов (если опция -h, то и HTML-файл, рис. 1), соответствующие распознанным типам блоков, которых lazarus смог определить. Кроме того, в каталоге blocks (определен в переменной $blocks в файле lazaruz.cf или, возможно, переопределить, использовав флаг -D) создаются файлы, которые содержат данные, найденные в блоках. Последовательные блоки того же самого типа считаются одним и тем же файлом и записываются в тот же самый выходной файл $blocks/*. Расшифровка выдаваемых значений видна на рис. 1.

Рисунок 1

Так, буква «T» означает текстовый файл, «M» – почтовый, «C» – код на Cи, точка «.» – файл неопределен. Хотя, бывает, утилита и ошибается. Далее процесс восстановления описан в документе help-recovering-file и lazarus.README, которые лежат в подкаталоге doc. Например, текстовые файлы с определенными словами можно попробовать найти при помощи grep:

# egrep -l 'keyword1|keyword2|...' blocks/*.txt > allfiles

Вы видите, насколько мощные и удобные инструменты имеются в TCT, но все же их возможностей явно не достаточно. Так, нельзя обеспечить анализ по имени файла, провести соответствие inodes с блоками, просмотреть информацию, находящуюся в отдельных блоках. Поэтому был разработан еще один комплект инструментов, дополняющих TCT, названный TCTUtils (http://www.cerias.purdue.edu/homes/carrier/forensics) и использующий его библиотеки. Принцип работы прост и основывается на том, что информация при удалении файла фактически сохраняется в записях каталога. Выглядит это в общем приблизительно так (некоторые подробности работы ext2 смотрите в [1]. Каталог имеет для каждого файла четыре существенные записи: номер inode, длина записи в байтах rec_len, округленная до 4, имя файла (name) и длина имени файла (nam_len). При удалении файла в целях экономии времени запись о нем не удаляется, просто к значению rec_len предыдущего файла добавляется длина удаляемого, т.е. фактически утилиты теперь проскакивают над записью удаленного файла. И теперь утилиты из TCTUtils, анализируя поля, определяют, у которого поле rec_len больше требуемого, и таким образом находят спрятанный файл.

Для компиляции TCTUtils потребуется наличие установленного TCT, путь к каталогу которого необходимо указать в файле src/Makefile в переменной TCT_DIR. После этого в подкаталоге bin появятся несколько исполняемых файлов.

# ls bin

bcat        blockcalc   find_file   find_inode  fls     istat

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

./istat /dev/hda9 107

inode: 107