Универсальное временное извлечение метаданных

Введение

Извлечение файлов (file carving) - это методика, которая идентифицирует и извлекает файлы из нераспределенных областей на основе сигнатур, найденных в содержимом файла, без использования метаданных файловой системы [1]. Несмотря на чрезвычайную полезность, извлечение файлов имеет несколько проблем. Во-первых, следователям необходимо решить, какие типы файлов извлекать. Чтобы сократить время извлечения, следователи часто выбирают типы файлов, которые, по их предположению, могут иметь отношение к уголовному делу. Например, при извлечении типичных файлов изображений в делах, связанных с сексуальным насилием над детьми, следователь ограничивает возможность идентификации других типов файлов. Кроме того, не все файлы имеют сигнатуру и не могут быть найдены с помощью извлечения файлов. Некоторые методы извлечения работают на основе предположения, что файлы имеют смежные блоки, что не срабатывает при попытке извлечь фрагментированный файл [1].

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

Мы восстанавливаем только метаданные файлов или каталогов из NTFS и Ext4, чтобы продемонстрировать применимость нового подхода, но подход может быть расширен для восстановления метаданных из других файловых систем. Чтобы достичь реалистичного сценария, мы переформатируем том с другой файловой системой, эффективно "повреждая" предыдущую файловую систему. Инструменты, разработанные в этой статье, являются прототипами, и основная целевая группа - эксперты по файловым системам с компетенцией для ручной оценки структур файловых систем. Инструменты и образы дисков можно загрузить для ознакомления по ссылке ([Nordvik et al., 2020]).

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

Наш подход фокусируется на структурах метаданных, найденных в записях MFT или inodes, извлеченных из нераспределенного пространства. Всегда существует риск, что блоки (кластеры), на которые указывают обнаруженные структуры метаданных, могут быть перезаписаны новыми или существующими выделенными файлами, но это может быть идентифицировано путем проверки выделенной битовой карты файловой системы на предмет выделенных блоков и путем сравнения метаданных с содержимым восстановленного файла.

Таблица 1: Файловые системы с близко расположенными временными метками в структурах метаданных

Файловая система	Совместно расположенные временные метки	Гранулярность
NTFS	4	64 бита - нс интервалы с 1.1.1601
ReFS	4	64 бита - нс интервалы с 1.1.1601
APFS	4 (5)	64 бита - нс с 1970
HFS+	4	32 бита - с с 1904
BTRFS	3 (4)	64 бита - с с 1970 + 32 бита (нс)
ExFAT	3	32 бита + смещение UTC
FAT	3	16 бит для времени (кроме доступа), 16 бит для дня
UFS1	3	32 бита - с с 1970 + 32 бита (нс)
UFS2	4	64 бита (нс) с 1970
Ext2/3	4	32 бита - с с 1970
Ext4	4	34 бита - с с 1970 + 30 бит (нс)

Большинство файловых систем имеют своего рода битовую систему, которая имеет биты, представляющие каждый блок (кластер), и выделенные блоки имеют соответствующий установленный бит [3, p.311].

Наш новый подход подходит для восстановления метаданных и содержимого файлов с устройств хранения, которые были переформатированы с другой файловой системой, с файловой системой того же типа, когда не оценивается выделенная таблица inode/файлов, или из вообще поврежденных файловых систем. Подход также полезен для поиска исторических структур метаданных, расположенных на диске, которые не содержатся в таблицах MFT или inode.

Подробные структуры файловых систем описаны в [Carrier (2005)]. Хотя его книга не включает детали о Ext4, она содержит большую часть базовой информации из Ext2 и Ext3. [Dewald and Seufert (2017)] включают больше деталей о Ext4.

Предположения

В настоящее время большинство файловых систем включают по крайней мере 3 смежных временных метки. Файловые системы Linux обычно используют временные метки MAC (Modified, Accessed и Changed) [3, p.297], например, Ext2 и Ext3 используют смежные atime (время доступа), ctime (время изменения inode), mtime (время изменения данных) и dtime (время удаления) [3, p.298]. Ext4 также содержит те же смежные временные метки, но добавляет crtime (время создания) в конце inode [Ext4 development team, 2019]. NTFS и ReFS используют 4 смежные временные метки (Создание, Изменение, Изменение MFT и Доступ) в нескольких атрибутах [Carrier, 2005; Nordvik et al., 2019]. В Таблице 1 показаны несколько файловых систем с близко расположенными временными метками.

Цели

• Можем ли мы надежно использовать время в качестве универсального идентификатора для извлечения структур метаданных файлов и каталогов в различных файловых системах?
• Какова надежность восстановления файлов с использованием обнаруженных метаданных в Ext4 и NTFS?

Мы стремимся идентифицировать структуры метаданных файлов или каталогов из различных файловых систем на основе общего идентификатора. В нашем случае - равные и близко расположенные временные метки, что позволит использовать универсальный подход для извлечения метаданных. Мы идентифицируем потенциальные временные метки с помощью простого алгоритма сопоставления строк, а затем интерпретируем семантику ожидаемых метаданных файловой системы, чтобы значительно сократить количество ложных срабатываний.

Идентификация метаданных недостаточна для соединения содержимого файла и метаданных, потому что содержимое может быть перезаписано выделенными файлами. Мы обсуждаем, почему важно выполнить ручную оценку как метаданных, так и содержимого и контекста, чтобы решить, можно ли соединить метаданные и содержимое файла.

Новизна нового подхода

Существующие методы извлечения метаданных не используют временные метки в качестве общего идентификатора (динамической сигнатуры) для различных файловых систем. Даже [Dewald and Seufert (2017)] описывают, что нет магической сигнатуры для inodes в файловой системе Ext4, и они зависят от семантики Ext4 для идентификации местоположений структур метаданных inode. Однако структуры метаданных можно легко найти с помощью сопоставления строковых шаблонов на основе равенства, но, к сожалению, с большим количеством ложных срабатываний, которые имеют схожие свойства. Таким образом, получается высокий показатель полноты (recall) и низкая точность (precision) для нахождения записей метаданных файловой системы. Мы также не зависим от начальной или конечной даты для идентификации временных меток. Эта независимость от даты и времени нашего подхода позволяет поддерживать любую файловую систему, имеющую близко расположенные временные метки. Хотя мы не зависим от другой семантики для идентификации местоположений этих потенциальных временных меток, мы используем семантические парсеры для проверки и значительного сокращения количества ложных срабатываний структур метаданных файловой системы.

Важность для цифровой криминалистики

Используя новый подход универсального временного извлечения метаданных, нам не нужно указывать, какие конкретные типы файлов извлекать. Подход не учитывает типы файлов или сигнатуры файлов; он извлекает только структуры метаданных, которые потенциально могут быть использованы для восстановления файлов. Точно соединяя метаданные с соответствующим содержимым файла, мы также увеличиваем доказательственную ценность восстановленных файлов, чего не достигает большинство существующих методов извлечения.

Организация статьи

Мы представили цели и новый подход универсального временного извлечения метаданных во введении. В разделе обзора литературы и вкладов мы обсуждаем текущее состояние дел, связанное с извлечением файлов и метаданных. В разделе метода мы описываем алгоритмы извлечения и методы, которые мы использовали для экспериментов, а в разделе результатов мы описываем наши результаты с использованием точности и полноты. Затем мы обсуждаем наши результаты в разделе обсуждения и делаем выводы в разделе заключения и дальнейшей работы.

Связанные работы и вклад

Было опубликовано значительное количество литературы по извлечению файлов, как с использованием извлечения на основе сигнатур, так и семантического извлечения конкретных типов файлов или других статистических подходов для идентификации и извлечения фрагментированных файлов. Мы рассматриваем литературу, более конкретно связанную с извлечением метаданных, поэтому полный список всей литературы по извлечению файлов будет выходить за рамки.

[Mueller (2008)] представил идею поиска временных меток NTFS как строки в нераспределенном пространстве, поскольку каждая временная метка составляет 64 бита и представляет количество наносекундных интервалов с 1.1.1601. Он также описывает, что временные метки находятся в группах по 4 смежные временные метки для каждой группы. Он создал EnScript (плагин для EnCase), который искал временные метки NTFS и помечал их. EnScript использует поиск grep для определенного диапазона дат и имеет опцию проверки следующих 8 байт, чтобы включать только совпадения, за которыми следует другая действительная временная метка. Использование поиска последовательных временных меток в идеале уменьшает количество ложных срабатываний, но, судя по комментариям к этому сообщению в блоге, похоже, что поиск последовательных временных меток работает некорректно.

Чтобы уменьшить количество ложных срабатываний, наша идея заключается в поиске набора идентичных временных меток в небольшом окне для обнаружения структур метаданных, описывающих файлы. Будут найдены только структуры метаданных с определенным количеством равных временных меток. Наш подход более универсален, поскольку нам не нужно знать, как форматируется временная метка (кроме того, что они близко расположены).

[McCash (2010)] основывал свою работу на EnScript от Muller [Mueller, 2008] и добавляет идею использования этой информации для обнаружения записей MFT и их атрибутов для извлечения содержимого данных. Он также описывает, что скрипт можно использовать для идентификации индексов каталогов и узлов ключей реестра.

Извлечение метаданных

[Dewald and Seufert (2017)] рассматривают случай, когда суперблок Ext4 или таблица дескрипторов групп повреждены или перезаписаны, и они используют либо режим метаданных, либо режим содержимого для анализа файловых систем или извлечения метаданных соответственно. В режиме содержимого их решение заключается в извлечении inodes, что потенциально предоставляет метаданные, необходимые для извлечения содержимого файла. Однако имя файла и номер inode не восстанавливаются в режиме содержимого. Поскольку inodes не имеют магических байтов (за исключением заголовков экстентов в Ext4), они описывают, что они извлекают их с помощью сопоставления шаблонов и анализа метаданных. Они приходят к выводу, что их подход может восстанавливать файлы из Ext4, несмотря на незнание конкретной структуры файловой системы. Однако они описывают, что им нужны несколько параметров Ext4 в режиме метаданных для анализа файловой системы. Они описывают, что эти параметры могут быть либо предоставлены пользователем, либо оценены на основе размера файловой системы.

Их работа показывает, что извлечение структур метаданных уже предлагается для восстановления файлов. Их подход в режиме метаданных явно зависит от семантики, специфичной для Ext4, чтобы включить как метаданные, так и содержимое файла, что позволяет анализировать файловую систему (а не извлекать). Их подход извлечения, режим содержимого, не может восстановить имя файла или номера inode.

[Plum and Dewald (2018)] описывают извлечение суперблоков контейнеров APFS, суперблоков томов или извлечение inodes. APFS использует несколько суперблоков контейнеров, и каждый из них может содержать ссылку на предыдущий суперблок контейнера. В каждом суперблоке контейнера они находят суперблоки томов, которые описывают конкретные тома. Они могут быть использованы для анализа конкретного тома и восстановления файлов из предыдущих состояний файловой системы. Они further описывают, что inodes не имеют конкретной сигнатуры, но они могут быть извлечены с помощью комбинаций полей типа объекта и подтипа inode. Эти inodes могут быть использованы для потенциального восстановления файлов с подключенными метаданными.

Их подход похож на работу [Dewald and Seufert (2017)], но отличается зависимостью от конкретной семантики APFS. Наш универсальный подход также будет работать для inodes APFS, поскольку каждый inode имеет набор смежных временных меток. Однако мы не реализовали семантический парсер для APFS.

Работа [Garfinkel (2013)] описывает инструмент Bulk_Extractor, который анализирует большой поток данных, используя несколько потоков, для извлечения признаков (URL-адреса, адреса электронной почты, условия поиска Google, данные Exif и т.д.), который использует оптимистичную декомпрессию перед извлечением признаков. Признаки обнаруживаются на основе правил, которые учитывают локальный контекст, что улучшает точность и полноту. Извлеченные признаки не обязательно должны находиться внутри записей файлов. Как часть результата, создаются гистограммы извлеченных признаков.

Оценка восстановленных файлов

[Casey et al. (2019)] описывают криминалистические процессы, такие как аутентификация, классификация и оценка восстановленных файлов. Проблема заключается в том, что разные инструменты восстановления не используют одинаковые названия для одного и того же. Они предлагают использовать "Потенциально Восстановленный" до выполнения аутентификации. Процесс аутентификации необходим для решения, является ли файл Полностью Восстановленным, Частично Восстановленным, восстановлены только Имя и Метаданные или восстановлено Имя. Решение должно основываться на уровне достоверности после тестирования или попытки опровергнуть различные сценарии или утверждения.

Метод

Мы используем универсальный автоматизированный подход для идентификации потенциального набора временных меток в пределах указанного порога. Затем мы записываем позиции байтов в файле образа, где был найден набор временных меток. Подход является универсальным, потому что он будет идентифицировать структуры метаданных в любой файловой системе, которая использует две или более временных меток пользовательского размера для описания временной информации файла или каталога. Поскольку наш подход основан на идентификации равенства между последовательностями байтов, нам не требуется время начала или окончания для временных меток. Этот подход увеличит уровень ложных срабатываний, но наши семантические парсеры пытаются исключить ложные срабатывания, проверяя, имеет ли каждое местоположение временной метки действительную структуру метаданных для конкретной файловой системы.

В качестве доказательства концепции мы добавили поддержку восстановления метаданных на основе идентифицированных временных меток в файловых системах Ext4 и NTFS.

Описание общего алгоритма потенциальных временных меток

Сначала мы описываем общий алгоритм потенциальных временных меток на высоком уровне. Мотивирующим фактором для этого алгоритма является то, что часто одна или несколько временных меток MAC идентичны. Кроме того, для записей файловой системы в NTFS, ReFS и ExtX временные метки близко расположены вместе в структуре метаданных. Пусть m - длина в байтах потенциальной временной метки, пусть T - массив байтов данных, в которых выполняется поиск. Пользователь определит длину m (ExtX требует m = 4, а NTFS требует m = 8), а также длину k байтов для поиска после потенциальной временной метки, которую мы называем порогом поиска. Суть этого подхода поиска заключается в том, что каждые неперекрывающиеся m байтов в наших двоичных данных T рассматриваются как ключевое слово поиска, и мы ищем повторения этой последовательности байтов размера m в пределах последующего окна порога k байтов, следующего за ключевым словом. Если данный байтовый шаблон встречается один или более раз в пределах этого окна порога, то мы идентифицировали потенциальную временную метку.

Механика алгоритма поиска основана на подходе "скользящего окна", как это часто встречается в анализе вредоносного ПО. Поиск начинается с T[0], в котором первые m байтов принимаются за потенциальную временную метку, содержащую значения T[0:m). Затем мы проверяем, эквивалентно ли это m-байтовое ключевое слово каждым неперекрывающимся m байтам в T[m:(m+k)), и ведем подсчет того, сколько точных совпадений произошло. Учитывая, что мы ищем временные метки, где по крайней мере две из них на структуру метаданных эквивалентны, если совпадений не найдено, мы затем продвигаем нашу позицию поиска на m байтов до позиции T[0+m]. Продвижение на m байтов предполагает, что временные метки всегда будут попадать на кратное m, и мы планируем реализовать функцию исчерпывающего поиска, которая проверяет временные метки на каждом одном или двух байтах. Такие размеры пропуска были выбраны для существенного увеличения скорости поиска, поскольку текущее решение для 8-байтовых временных меток будет обрабатывать образ диска в 8 раз быстрее, чем альтернатива исчерпывающего поиска, которая проверяет потенциальные временные метки на каждом отдельном байте. Если найдено одно или более совпадений, мы продвигаем нашу позицию поиска на k байтов до позиции T[0+k].

В любом случае вся процедура поиска повторяется с нашей новой позиции поиска. Этот процесс повторяется для всех данных T, за исключением последних k байтов порога. Размер пропуска k был выбран как минимальный размер, чтобы избежать множественных попаданий для одной и той же структуры метаданных. Обратите внимание, что для нашей текущей реализации k должно быть кратно m, иначе байты, в которых выполняется поиск, будут не выровнены с фактическими временными метками образа диска. Алгоритм 1 предоставляет псевдокод базового алгоритма извлечения потенциальных временных меток.

Мы предоставляем иллюстрацию для дальнейшего объяснения. На Рис. 1 подчеркнутые байты представляют ключевое слово потенциальной временной метки с m = 8, а скобки представляют порог байтов, k = 24, в котором ищутся совпадения.

Этот общий поиск сам по себе, вероятно, производит большое количество ложных срабатываний, поэтому мы добавили дополнительное условие для улучшения точности алгоритма. Мы определяем, состоит ли потенциальная временная метка, которую нужно искать, из одного повторяющегося байтового значения, и если да, то пропускаем процедуру поиска и перемещаемся вперед на m байтов. Это позволяет избежать бесплодных поисков в блоках повторяющихся байтов. Примерами таких временных меток, которых мы хотим избежать, являются 0x0000000000000000 и 0xFFFFFFFFFFFFFFFF.

Здесь мы приближаем временную сложность наихудшего сценария поиска. Мы предполагаем, что весь образ диска может быть считан в память сразу, чтобы упростить наше приближение. В этом сценарии мы ищем образ диска без наборов совместно расположенных байтов, которые повторяются два или более раз (мы не получаем попаданий). Таким образом, мы не можем выполнить никакие пропуски окон байтов после поиска в нашем пороге окна поиска. Мы также выполняем самый общий тип извлечения потенциальных временных меток, где мы не рассматриваем повторяющиеся байтовые последовательности. Таким образом, мы не можем пропустить какую-либо конкретную ключевую байтовую последовательность, поскольку все байтовые последовательности будут считаться потенциально действительными временными метками. Следовательно, каждая m последовательность неперекрывающихся байтов в массиве байтов образа диска T будет иметь выполненную процедуру поиска, в которой ищется все окно порога размера k.

Учитывая этот наихудший сценарий, вычислительная временная сложность составляет O(|T|/m × k/m). Целое число от мощности T, деленного на m, - это количество байтовых последовательностей, для которых выполняется процедура поиска, и оно умножается на максимальное количество проверок совпадения байтов, порог байтов k, деленный на m, где m является множителем k.

Детали практической программы потенциальных временных меток

Общий алгоритм извлечения временных меток был реализован на C++, который мы называем cPTS, и поддерживается рядом библиотек. Поскольку анализируемые образы дисков, вероятно, больше памяти, мы используем кроссплатформенную библиотеку отображения памяти mio. Это позволяет нам считывать 1 ГБ памяти за раз и читать образ как серию массивов. Однако, как только средство извлечения потенциальных временных меток достигает последних 4096 байтов гигабайта в памяти, мы загружаем новый гигабайт в память с точки поиска относительно диска, чтобы обрабатывать записи каталогов, которые распределены по сегментам. Для преобразования форматов даты и времени в десятичную форму мы использовали библиотеку Date. Программа выводит текстовый файл со списком всех местоположений потенциальных временных меток (в смещении байтов), которые были найдены.

Семантические парсеры

Идентификация близко расположенных потенциальных временных меток на основе равенства предоставит универсальные результаты, но будет содержать много ложных срабатываний из-за своей универсальности. Поэтому были разработаны парсеры, которые используют семантику ожидаемых структур метаданных конкретных файловых систем для более точной автоматизации. Наши парсеры на Python 3 принимают местоположения временных меток от универсального средства извлечения временных меток и образ диска в качестве входных данных, как показано на Рис. 2. Наши эксперименты используют этот процесс.

Семантический парсер NTFS

Скрипт NTFS оценивает, находится ли потенциальная временная метка в Атрибуте Стандартной Информации (SIA) или в Атрибуте Имени Файла (FNA). Чтобы уменьшить количество ложных срабатываний, мы исключаем любые потенциальные временные метки до 1970 года и после 2100 года. Скрипт выводит информацию метаданных, содержащуюся в SIA, FNA и Атрибуте Данных, если возможно. При попытке разобрать полную запись MFT мы начинаем с идентификации SIA. Как только мы идентифицируем местоположение заголовка SIA, мы используем длину SIA, чтобы увидеть, что представляет собой заголовок следующего атрибута, в конечном итоге ища Атрибут Данных. Если следующий заголовок атрибута не является Атрибутом Данных, и первый байт типа атрибута меньше 0x80, мы читаем длину атрибута и выполняем еще один переход к следующему атрибуту. Однако, если следующий атрибут является FNA, мы выведем его информацию метаданных и добавим байтовое местоположение его первой временной метки в список будущих временных меток, которых следует избегать. Это делается для того, чтобы мы не получали избыточные выводы FNA. Обнаружение по крайней мере одного FNA требуется для чтения потенциального Атрибута Данных, который мы встречаем. Это повторяется до тех пор, пока мы не найдем Атрибут Данных, или не прекращается, если мы идентифицируем тип атрибута, где его первый байт больше 0x80 или если мы искали больше, чем длина потенциальной записи MFT. Ограничением этой работы является то, что мы в настоящее время не выполняем поиск записей MFT, начиная с идентифицированных Атрибутов Имени Файла, где их временные метки с большей вероятностью будут надежно найдены из-за их относительно неизменной природы по сравнению с Атрибутами Стандартной Информации [Cho, 2013]. Другим ограничением является то, что мы в настоящее время не поддерживаем Альтернативные Потоки Данных. Соответствующая информация записи MFT выводится в файл NTFSResults.txt, и если файл является резидентным, мы также включаем резидентный файл, закодированный в ASCII.

Семантический парсер Ext4

Скрипт Ext4 на Python 3 использует текстовый файл, созданный инструментом cPTS, содержащий местоположения потенциальных временных меток, образ диска, позицию байта, где начинается раздел, и предполагаемый размер блока. Для проведения поиска, аналогичного выполненному в парсере NTFS, эти параметры и статический размер inode по умолчанию 256 байтов - единственные предположения, которые мы делаем.

Как и парсер NTFS, мы используем потенциальные временные метки как точки привязки и тестируем различную семантику на локальных смещениях. Но теперь мы также проверяем информацию, найденную в вероятных записях каталогов. Для Ext4 мы тестируем все возможные смещения назад для флагов файлов, представляющих интерес: 0x04 для каталогов, 0x08 для обычных файлов и 0x0A для символических ссылок. Для inodes Ext4, не использующих экстенты, мы обеспечиваем, чтобы относительная позиция байтов 36-39 inode не использовалась. Для inodes, использующих экстенты, мы проверяем, что относительная позиция его магического числа заголовка экстента равна 0xF30A. Затем мы проводим дополнительные тесты, чтобы увеличить вероятность обнаружения inode, такие как использование некоторых тестов согласованности временных меток Dewald и Seufert [Dewald and Seufert, 2017], что размер файла соответствующим образом соответствует количеству секторов, и что размер файла не может превышать размер образа диска. Все inodes, найденные достаточно действительными, имеют свои вероятные начальные точки, добавленные в список.

Большая трудность при выполнении полного извлечения файлов в Ext4 заключается в соединении inodes и их записей каталогов, когда не полагаются на суперблоки, таблицы дескрипторов групп блоков или битовые карты inode. Такие соединения необходимо будет установить, если эти структуры метаданных невосстановимы. Inode содержит большую часть метаданных для файла, но связанная с ним запись каталога содержит имя файла и номер inode. Задачей было затем соединить inodes на основе их физического положения с их фактическим номером inode. Мы стремились решить эту проблему, полагаясь исключительно на информацию, которую мы можем найти локально внутри или вокруг проверенного inode.

Наше решение вращается вокруг использования проверенных inodes каталогов, которые не были удалены, так как это дает нам достоверную информацию о номерах inode и именах файлов, включая номер inode самого каталога. Проверка выполняется путем следования экстенту каталога или прямому указателю блока к его первой записи каталога и проверки, являются ли байты 4-6 равными 0x0C0001 (длина записи и первый байт длины имени). Для Ext4 мы выполняем два прохода по образу диска. Первый проход собирает информацию о действительных inodes, создавая словарь номеров inode и имен файлов, найденных во всех проверенных каталогах, а также так называемый список синхронизации. Этот список синхронизации - это запись первого проверенного inode каталога, найденного в group block, в которой мы записываем местоположение и номер inode inode. Второй проход использует словарь inode и список синхронизации для оценки номеров inode проверенных inodes, выводя номер inode вместе с его вероятным именем файла.

Мы можем оценить номер inode потенциальных inodes двумя разными способами. Первый способ использует позиции, найденные в списке синхронизации inode, где мы затем можем сделать оценки номеров inode проверенных inodes, которые находятся в той же группе блоков, что и проверенный каталог, используемый из списка синхронизации inode. Предполагая, что inodes Ext4 имеют статический размер 256 байтов, следующее уравнение оцениваемого номера inode e, где dn представляет номер inode проверенного каталога, используемого из списка синхронизации inode, vl представляет местоположение проверенного inode, и dl представляет местоположение inode того же каталога, полученного из списка синхронизации inode:

e = dn + ((vl - dl) / 256)

Используя список синхронизации inode, мы можем оценить номера inode до встречи с каталогом, в котором хранятся его имя файла и номер inode (в случае удаления). Во время второго прохода (пока мы оцениваем номера inode), при встрече с проверенным inode каталога, мы обновляем запись в списке синхронизации inode для текущей группы блоков, в которой мы находимся. Это позволяет осуществлять довольно локальную синхронизацию текущего номера inode. Второй способ оценки номеров inode использует предыдущие оценки и словарь inode. Первый раз, когда мы делаем оценку для конкретного номера inode, мы обновляем его запись в словаре inode, добавляя номер версии файла inode и время создания в качестве параметров. Если номер inode не существовал в словаре до оценки inode, мы просто создаем запись с этими параметрами. Как только запись была обновлена или создана, она не может измениться. Номер версии файла и время создания должны быть относительно уникальными per inode, и поэтому при разборе будущих inodes мы проверяем, записали ли мы уже его номер версии файла и время создания в словаре inode, и выводим связанный записанный номер inode и имя файла.

Мы выводим текстовый файл и csv-файл, ExtResults, где мы записываем соответствующую информацию inode и записи каталога. Мы перечисляем как оцененный номер inode и имя файла (используя номер inode как ключ в словаре inode), так и записанный номер inode и имя файла (используя номер версии файла как ключ в словаре inode).

Экспериментальная установка

Мы использовали внешнюю USB-флешку и очистили раздел с помощью инструмента dc3dd v. 7.2.646 [Department of Defence Cyber Crime Center, 2012] в macOS Mojave v. 10.14 (также можно использовать Linux).

Эксперимент - NTFS переформатирован в exFAT

Мы отформатировали устройство в Windows 10 с помощью NTFS, где мы создали 50 файлов, и для каждого типа файлов мы назвали их File1, File2, File3,..., File10. Использовались пять различных типов файлов, и для каждого из этих типов файлов было по 10 файлов, где расширения добавлялись к имени файла. Затем мы переформатировали файловую систему с помощью exFAT. Фрагменты или полная таблица MFT все еще должны быть доступны. Наконец, 10 текстовых файлов были добавлены в переформатированный образ.

Файлы, созданные пакетным файлом, дают нам известную основу для тестирования точности и полноты. Мы знаем все имена файлов и содержимое, так как базовый криминалистический образ (ntfsbase.dd) раздела был создан до его переформатирования в exFAT. После переформатирования и создания 10 текстовых файлов мы создали новый криминалистический образ раздела (nftsexfat.dd) с помощью dc3dd.

Мы измерили уровень ложных срабатываний и ложных пропусков, сравнивая результаты извлечения метаданных с именами файлов, которые мы нашли в ntfsbase.dd. Ложное срабатывание - это место попадания, не найденное в метаданных, описывающих файл или каталог, в то время как ложный пропуск - это набор временных меток, не идентифицированных как попадание, но который расположен в метаданных, описывающих файл или каталог. Наконец, мы рассчитали точность и полноту [Perry et al., 1955] реализованных методов.

Мы использовали размер временной метки 8 байтов, порог поиска 24 байта для поиска эквивалентных временных меток, где по крайней мере 3 временные метки равны. Вывод из Листинга 2 был сохранен в файл cPTS.txt.

Эксперимент - предыдущий Ext4 переформатирован в NTFS

Следующим шагом была оценка, является ли каждое попадание частью атрибута стандартной информации (SIA) или атрибута имени файла (FNA). Затем скрипт в Листинге 3 идентифицирует Атрибут Данных и показывает резидентные данные или нерезидентные прогоны данных.

Дополнительно мы проверили, могут ли X-Ways, EnCase и EaseUS Data Recovery Wizard (ранее названный Recuva) восстановить предыдущий раздел NTFS или найти нераспределенные записи MFT, используя тот же криминалистический образ.

Для эксперимента Ext4 мы использовали Linux Mint 18.2 и Windows 10. В Linux мы очистили устройство хранения с помощью команды shred, перезаписывая нулями. Затем мы отформатировали устройство хранения с Ext4 и смонтировали его. Мы создали 50 каталогов с 500 файлами в каждом каталоге. Файлы были пронумерованы от 1.txt до 25000.txt. Имена файлов соответствуют количеству байтов (a's) в каждом файле. Текстовые файлы были выбраны потому, что их сложнее восстанавливать инструментам извлечения, так как нет сигнатуры. Поэтому восстановление этих текстовых файлов зависит исключительно от метаданных. Файловая система была размонтирована, и был создан исходный криминалистический сырой образ с именем expExt4.dd с помощью dd. Затем он был смонтирован в ОС Windows 10 и переформатирован с NTFS с размером кластера 4096 байт. Затем было создано 10 файлов. Был создан сырой образ с именем Ext4NowNTFS.dd.

Мы использовали размер временной метки 4 байта, порог поиска 12 байтов для поиска равных временных меток, где по крайней мере 2 временные метки равны. Вывод из Листинга 4 был сохранен в файл cPTS.txt.

В Листинге 5 мы начинаем с смещения байта 0 в образе, размер блока составляет 4096 байтов, блоков на группу оценивается как размер_блока*8 = 32768.

Ограничения

Мы не знаем в начале расследования, была ли предыдущая файловая система. Мы предлагаем искать известные сигнатуры загрузочных записей томов/суперблоков, которые могут документировать начало предыдущего раздела. Мы также предлагаем попытаться восстановить раздел перед попыткой нашего подхода извлечения метаданных.

Результаты вывода прототипа должны быть оценены экспертами по файловым системам (или экспертными системами), чтобы оценить, может ли файл (имя, метаданные и содержимое) быть полностью или потенциально восстановлен. Это называется аутентификацией и включает оценка классификатора, результатов и, наконец, уверенное решение [Casey et al., 2019].

Наш инструмент-прототип не будет работать должным образом на манипулированной файловой системе, где секторы или кластеры удалены или добавлены, потому что отображение между прогонами данных (экстентами) и местоположениями кластеров не синхронизировано. Наш подход зависит от существования структур метаданных в нераспределенной области раздела, и мы предполагаем, что начало прогона данных (указатель блока экстента) относительно начала раздела. Прототип также не учитывает значения исправления, найденные в последних двух байтах каждого сектора в записи MFT.

Поскольку как SIA, так и FNA находятся среди первых атрибутов в записи MFT, мы предполагаем, что они обычно не будут найдены без fixup значения. Мы не рассматриваем файлы, которые используют несколько записей MFT, если Атрибут Данных не расположен в первой из этих записей MFT. В настоящее время реализованные семантические парсеры не рассматривают FNA в индексах каталогов, но инструмент cPTS будет их находить. Наконец, мы не рассматриваем размеры записей inode Ext4, отличные от стандартных 256 байтов.

Мы осознаем, что наши эксперименты имеют небольшой размер выборки, и мы не включили тестирование на реальных криминалистических образах из реальных уголовных дел, чтобы соблюдать законодательство. Мы также осознаем, что мы тестировали только с использованием конкретных версий Linux и Windows, что открывает возможность отклонений, если выбраны другие ОС. Мы выбрали эту небольшую выборку, потому что она позволяет нам знать исходную истину содержимого, что сложно при использовании системного тома, где ОС continuously создает и удаляет файлы. Использование неизвестного источника затрудняет вычисление точности и полноты и не дает нам контроля над различными переменными, которые могут повлиять на результаты.

Результаты

Команда cPTS заняла 13 с для запуска на файле образа dd размером 2 ГиБ. ntfsParser.py занял менее 1 с, в то время как ext4parser.py занял 8 с. Это быстрее, чем производительность во время выполнения инструментов Dewald и Seufert [Dewald and Seufert, 2017], однако они дополнительно автоматически экспортировали содержимое файла.

Извлечение метаданных NTFS

Для каждой обнаруженной записи MFT мы знаем, что SIA связан с FNA, потому что расстояние между ними меньше 1024 байтов, что можно визуально проверить или опровергнуть, интерпретируя местоположение байта для попаданий временных меток SIA и FNA. Атрибут Данных принадлежит FNA, потому что мы переходим к следующему атрибуту, пока не найдем неназванный Атрибут Данных, который мы нашли в пределах следующих 1024 байтов. Это означает, что у нас есть имя, метаданные и содержимое, и поскольку у нас есть прогоны данных, мы знаем, что эта запись является нерезидентной и потенциально восстанавливаемой. Чтобы проверить, можно ли соединить исходное содержимое с метаданными, нам нужно извлечь содержимое и выполнить проверку гипотез. Извлечение содержимого на основе известных прогонов данных описано в [Carrier (2005)].

Таблица 2: Точность и полнота для нахождения записей MFT в ntfsexfat.dd

	TP	FP	FN	Точность	Полнота
Совпадения SIA	162	1	0	0.9939	1

В Таблице 2 мы фокусируемся на файлах/каталогах и Атрибутах Стандартной Информации (SIA). Мы знаем, что каждая базовая запись MFT имеет один SIA. Поскольку у нас есть 79 файлов (50 файлов и 29 системных сгенерированных файлов и каталогов) в нашем эксперименте, мы знаем, что должно быть 79 SIA в таблице MFT. Мы также знаем, что должно быть 79 SIA в \$LogFile и 4 SIA в \$MFTMirr [3, p.303]. Это дает в общей сложности 162 SIA. Мы нашли все 162 SIA, и только одно из попаданий было ложным срабатыванием. У нас не было ложных пропусков для SIA. Наше вычисление точности и полноты показано ниже.

Точность = Истинные положительные / (Истинные положительные + Ложные положительные) = 162 / 163 = 0.993

Полнота = Истинные положительные / (Истинные положительные + Ложные отрицательные) = 162 / 162 = 1

Для нашего простого эксперимента было легко проверить найденные записи MFT с известной базой. Однако с криминалистическим образом из реального уголовного дела must быть выполнена проверка гипотез, чтобы убедиться, что прогоны данных, найденные в записях MFT, все еще могут быть connected к содержимому файла, и что они не полностью или частично перезаписаны другим файлом.

Попадания из \$LogFile

В дополнение к записям в таблице MFT и MFTMirr, мы нашли записи MFT within нераспределенного \$LogFile, но в этом случае они не включали прогоны данных или резидентные данные. Было интересно наблюдать, что наши созданные файлы имели Атрибут Данных within \$LogFile с размером только 0x18 байтов, который содержит только заголовок атрибута. Это означает, что мы не можем полностью восстановить файлы из всех записей MFT, найденных в \$LogFile.

Извлечение метаданных Ext4

Мы смогли восстановить все записи метаданных inode, которые не были перезаписаны NTFS, но переформатирование Ext4 в NTFS в нашем эксперименте стерло approximately 20257 inodes из таблицы inode. При использовании flex groups, таблицы inode все расположены continuously в первой группе блоков [Dewald and Seufert, 2017], вместо того чтобы быть разделенными на соответствующую группу блоков. Наши текущие наблюдения показывают, что наш подход поддерживает оба типа и не зависит от информации из дескрипторов групп блоков. Для каждого экстента, найденного в inode, извлечение содержимого файла легко выполняется путем извлечения из начального блока экстента, а также количества блоков, содержащихся в этом экстенте. Удаленный inode обычно будет иметь обнуленные экстенты, делая соединение inode с содержимым файла невыполнимым. Однако, поскольку мы находим попадания для дубликатов inodes в разных физических местоположениях, мы можем быть способны восстановить содержимое файла, используя экстенты, найденные в этих дубликатах. Мы не извлекали файлы из перезаписанного образа Ext4 из-за их количества и, таким образом, only обнаруживаем потенциально восстановленные файлы.

Чтобы измерить точность и полноту, мы создали те же образы dd Ext4 снова, следуя тому же методу, как описано ранее, но дополнительно мы добавили реальный номер inode как атрибут к каждому inode для 25000 текстовых файлов и 50 каталогов, которые мы создали в эксперименте, используя команду Linux attr. Таким образом, мы могли сравнить наш оцененный номер inode и записанный номер inode с реальным номером inode, включенным в атрибут.

Для оригинального и переформатированного образов мы провели два эксперимента точности и полноты. Первый вычисляет точность приписывания нашего записанного или оцененного номера inode к истинному номеру inode inode, и мы также вычисляем полноту нахождения наших известных файлов с правильным приписыванием. Для вычисления полноты, если по крайней мере один inode per номер inode был найден и мы правильно оценили или записали его номер inode, это считалось истинным положительным, где дубликаты inodes (относительно его истинного номера inode) были удалены. Для этих вычислений точности и полноты мы рассматривали only inodes, которые мы извлекли и которые содержали их истинный номер inode как атрибут. Таблица 3 показывает наши результаты для непереформатированной версии файла dd. Подобный процесс был выполнен для переформатированного файла dd, как видно в Таблице 5, за исключением того, что вместо вычисления полноты мы просто записываем количество обнаруженных inodes per метод оценки номера inode. Это было сделано, так как мы не можем быть уверены, сколько ложных отрицательных результатов было due нашим методам или переформатированию файловой системы (мы не можем найти то, что перезаписано). Обратите внимание, что since по крайней мере 20257 из 25050 inodes были стерты из их таблиц inode, и мы восстанавливаем 5755 inodes, что мы потенциально восстанавливаем по крайней мере 963 previously перезаписанных inodes.

Таблица 3: Точность и полнота для нахождения и приписывания номеров iNode для известных файлов в expExt4Attr.dd

	TP	FP	Точность	Полнота
Совпадения записанного inode с Истинным inode	77481	0	1	1
Совпадения оцененного inode с Истинным inode	27336	50145	0.3528	1
Совпадения оцененного или записанного inode с Истинным inode	77481	0	1	1

Таблица 4: Точность классификации iNode для непереформатированного образа

TP	FP	Точность
77675	0	1

Таблица 5: Точность и найденные файлы для нахождения и приписывания номеров iNode для известных файлов в Ext4AttrNowNTFS.dd

	TP	FP	Точность	Найденные файлы
Совпадения записанного inode с Истинным inode	15544	41692	0.2716	4848
Совпадения оцененного inode с Истинным inode	7091	50145	0.1239	5755
Совпадения оцененного или записанного inode с Истинным inode	16553	40683	0.2892	5755

Второй эксперимент вычисляет точность нашего метода для правильной классификации inodes, независимо от того, были ли они из известных файлов или нет. Ложные положительные в этом случае - это попадания inode, которые содержат мусорную информацию. Таблица 4 показывает точность из непереформатированного эксперимента, а Таблица 6 показывает точность переформатированного эксперимента. В обоих экспериментах мы получили 100% точность. Мы не можем вычислить полноту в этом случае, так как мы не можем знать, сколько inodes (из таблиц inode и копий диска) существует на образе.

Таблица 6: Точность классификации inode для переформатированного образа

TP	FP	Точность
57427	0	1

Коммерческие инструменты

Результаты тестирования инструментов, описанные в этом разделе, показаны в Таблице 7.

Таблица 7: Тестирование инструментов - Извлечение метаданных из предыдущей файловой системы при переформатировании с другой файловой системой

	EnCase	X-Ways	EaseUS	Bulk_Extr	cPTS
Метаданные NTFS	N	N	Y?	Y	Y
Inode Ext4	N	N	N	N	Y

NTFS переформатирован в exFAT

Мы создали дело в X-ways v 19.8 и импортировали файл ntfsexfat.dd. Используя функцию refine volume snapshot, мы выбрали particularly тщательный поиск структуры данных файловой системы и отметили search FILE records everywhere. Руководство X-ways описывает, что этот поиск должен быть able найти записи MFT из нераспределенного пространства. Однако инструмент не нашел ни одной из записей MFT из предыдущей файловой системы NTFS.

X-Ways также имеет функцию, которая должна быть способна сканировать на наличие потерянных разделов, но эта функция не смогла обнаружить предыдущий раздел. Мы искали записи MFT, но X-Ways не нашел записи MFT из предыдущего раздела.

Мы также попытались извлечь содержимое файла (за исключением текстовых файлов), и X-Ways смог извлечь непрерывные файлы, но не tiff файлы, которые имели два фрагмента.

EnCase v8.08 не смог найти записи MFT из предыдущего раздела NTFS в ntfsexfat.dd. Мы выбрали путь Full Investigation, который включает соответствующие Recover Folders (которые должны находить скрытые файлы в томах FAT и NTFS), и Windows Artifact Parser с выбранными MFT Transactions. Согласно руководству EnCase, опция Recover Folder должна быть able восстанавливать файлы NTFS из нераспределенных кластеров. Поскольку EnCase является инструментом с закрытым исходным кодом, мы не знаем, как это реализовано. EnCase нашел Backup VBR (Volume Boot Record), когда мы искали его с помощью Partition Finder. Однако восстановить раздел в disk view было невозможно.

Мы попытались использовать EnCase для извлечения файлов изображений (bmp, jpg, png и tiff). Содержимое всех 10 файлов bmp было найдено, но также 178 дополнительных ложных срабатываний. Содержимое каждого из 10 файлов jpg было найдено, и без ложных срабатываний. Мы пропустили один из файлов png, но нашли остальные. EnCase не нашел ни одного из файлов tiff. Это потому, что EnCase искал сигнатуры tiff 49492A000A, 49492B00, 4D4D002A, 4D4D002B, в то время как файл tiff, созданный в Windows 10, имел сигнатуру 49492A008E.

Мы протестировали устройство хранения, на котором мы проводили эксперимент, с EaseUS Data Recovery Wizard v11.15, и оно смогло идентифицировать все 50 файлов и их содержимое. Поскольку этот инструмент с закрытым исходным кодом, мы предполагаем, что они выполнили восстановление раздела, используя резервную копию VBR. Для восстановления раздела они показали только размер, дату создания и путь. Он также извлекал файлы, но извлеченные файлы не включали метаданные. Наконец, мы обнаружили, что инструмент не может правильно извлечь фрагментированные файлы или текстовые файлы.

Ext4 переформатирован в NTFS

Извлечение ASCII текстовых файлов не поддерживается EnCase v8.08, и поэтому извлечение ASCII текстовых файлов в предыдущей файловой системе Ext4 невозможно. Однако мы попытались извлечь 10 различных поддерживаемых типов файлов и измерили время выполнения, которое составило 27 с на образе диска 2 ГиБ. Затем мы попробовали 100 различных поддерживаемых типов файлов, что заняло about 1 мин. Наконец, мы выбрали все 349 поддерживаемых типов файлов, но мы отменили прогресс после 6 ч.

Мы выполнили тест с помощью инструмента EaseUS Data Recovery Wizard v11.15, но он не нашел ни одного из 25000 текстовых файлов within экспериментального носителя данных. Все 16 файлов, которые он перечислил, были выделенными файлами NTFS, и он не нашел никакого предыдущего раздела Ext4.

Дополнительное тестирование

Чтобы идентифицировать ожидаемое количество ложных срабатываний с помощью наших инструментов, мы выполнили дополнительное тестирование на реальном сыром образе 16 ГиБ из сотового телефона, который не имел никаких записей MFT, и на машине Windows 10 на 80 ГиБ без inodes Ext4. При поиске inodes в образе Windows мы нашли 3 ложных срабатывания, и при поиске записей MFT на образе сотового телефона мы нашли 8 ложных срабатываний.

Наконец, мы попробовали запустить Bulk_Extractor на наших переформатированных образах, wherein он нашел все имена файлов записей MFT в обоих образах, но не восстановил никакой информации метаданных из Ext4.

Обсуждение

В наших экспериментах мы переформатировали одну файловую систему с другой файловой системой. Если мы знаем, что она была переформатирована, мы можем сначала попытаться восстановить предыдущую файловую систему, оценив резервную копию VBR или суперблоки. Это может потенциально восстановить файловую систему, и мы можем точно найти файлы, которые другая файловая система не перезаписала. Однако, если другая файловая система перезаписала части предыдущей файловой системы, тогда нам может понадобиться использовать наш подход, чтобы найти части, которые не перезаписаны.

Обсуждение, связанное с NTFS

Для попаданий временных меток, где мы нашли записи MFT NTFS с резидентным атрибутом данных, мы можем reliably соединить метаданные и содержимое файла [Casey et al., 2019]. Это потому, что резидентные данные находятся within записи MFT. Обычное извлечение файлов не найдет маленькие ASCII текстовые файлы, которые являются резидентными в записях MFT, потому что эти файлы не имеют сигнатуры within их содержимого.

Записи MFT могут потенциально быть найдены в нескольких источниках; дампы памяти, нераспределенное пространство, в выделенных системных файлах, таких как \$MFT, \$MFTMirr, \$LogFile, hiberfil.sys и т.д. Выделенный \$MFT должен normally быть точным, если не манипулирован.

Наш подход не нуждается в полной таблице MFT, ни в полной записи MFT. Например, мы не используем заголовок записи MFT вообще. Однако мы полагаемся на то, что атрибуты SIA, FNA или Data совместно расположены вне размера типичной записи MFT. Это позволяет восстанавливать частично перезаписанные метаданные. В настоящее время мы не ищем Атрибут Данных, если SIA не найден, но мы планируем изменить эту зависимость в более поздних выпусках инструмента. Это изменение позволит обнаруживать FNA в индексных записях.

Нам нужно использовать \$Bitmap новой файловой системы, чтобы идентифицировать, какие кластеры/блоки используются. Если прогон данных, найденный в восстановленной структуре метаданных, использует один или more кластеров, выделенных файлом в новой файловой системе, мы должны предположить, что содержимое файла частично перезаписано.

Важно, чтобы следователь был знал о файловых системах, найденных при использовании нашего подхода. Прежде всего, наш подход использует прогоны данных, найденные метаданных NTFS, и первый прогон данных для записи MFT относительно начала файловой системы, и нам нужно использовать правильный размер кластера, использованный предыдущей файловой системой NTFS. Кроме того, последующие прогоны данных относительно предыдущего прогона [Carrier, 2005, p.258].

Поскольку мы предлагаем универсальный подход, мы не можем автоматизировать извлечение файлов без учета конкретного контекста, что требует контекстно-зависимых инструментов восстановления или ручной экспертной оценки. Например, носитель данных мог сначала иметь файловую систему NTFS, а затем быть переформатирован с NTFS или другой файловой системой. Тогда, конечно, контекст отличается и должен быть принят во внимание.

Мы показали, что популярные инструменты цифровой криминалистики, такие как текущие версии X-Ways или Encase, не обязательно находят записи MFT, когда система NTFS переформатирована в exFAT. Это может ошибочно заставить следователя использовать извлечение файлов, которое, конечно, не включает метаданные, а only содержимое файла. Такие действия приведут к пропуску соответствующих файлов и частично восстановленных фрагментированных файлов.

Обсуждение, связанное с Ext4

Если пользователь удалил файлы с помощью инструмента командной строки rm или опустошив корзину, некоторые из важных полей в удаленных inodes устанавливаются в 0, например, общий размер, количество ссылок, количество экстентов и поля экстентов. Временные метки для измененного, модифицированного и удаленного устанавливаются на время удаления, в то время как доступ и создание не изменяются. Однако, поскольку мы можем найти дубликаты inodes в местоположениях таблиц inode, мы можем найти предыдущие версии удаленного inode, что может позволить нам восстановить содержимое и метаданные.

Решение наших статистических данных и текущих проблем

Статистика: Наша высокая точность и полнота не указывают на то, что наш инструмент найдет почти все записи метаданных без ошибок, но это указывает на то, что он будет работать хорошо при условии, что структуры метаданных включают повторяющиеся временные метки. При создании образов дисков файлы гарантированно имели по крайней мере две или three идентичные временные метки. Если наше текущее решение применяется на реалистичном образе диска, процент идентифицированных записей метаданных должен быть таким же, как процент записей метаданных на диске, которые имеют идентичные временные метки.

Остатки метаданных: Наш подход не различает записи MFT/inodes, найденные в таблице MFT/inode, и экземпляры, найденные в журнале или elsewhere. Это не ограничение, это особенность, поскольку остатки из структур метаданных, описывающих файлы, могут быть разбросаны по файловой системе.

Виртуальные машины: Мы предполагаем, что не вся виртуальная память в Виртуальной Машине очищается при создании. Это означает, что могут быть остатки метаданных из предыдущих файловых систем хоста, если область, назначенная виртуальной памяти, была выделена для таблицы MFT/inode или для предыдущего журнала. Наш подход также найдет эти местоположения временных меток.

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

Заключение и дальнейшая работа

Целью этого исследования было ответить на следующие исследовательские вопросы.

• Можем ли мы надежно использовать время в качестве универсального идентификатора для извлечения структур метаданных файлов и каталогов в различных файловых системах?
• Какова надежность восстановления файлов с использованием обнаруженных метаданных в Ext4 и NTFS?

Мы показали, что набор похожих временных меток может быть использован как форма динамической сигнатуры (магического идентификатора), и мы извлекаем их, используя простой алгоритм сопоставления байтов. Затем мы используем семантику файловой системы, чтобы интерпретировать структуры метаданных, и вручную извлекаем резидентные или нерезидентные файлы. Наконец, эксперт по файловым системам оценивает классификацию, аутентификацию и принимает решение для окончательной классификации вручную восстановленных файлов.

Мы утверждаем, что ручная оценка надежности соединения между метаданными и содержимым файла необходима, и что эта оценка основана на контексте и должна быть ручной для нерезидентного содержимого файла. Однако ручная оценка может быть поддержана автоматизированными инструментами.

Соединение номера inode и имени файла является сложной задачей в Ext4, когда таблица inode частично стерта. Однако соединение метаданных inode с соответствующим содержимым файла все еще возможно даже без правильного номера inode или имени файла. На непереформатированном образе Ext4 мы смогли достичь точности и полноты при приписывании номеров inode к извлеченным inodes файлов и каталогов, которые мы разместили на образе. Для переформатированного образа Ext4 было возможно достичь более 28% точности в правильном приписывании номеров inode к извлеченным inodes файлов и каталогов, которые мы разместили на этом образе. Из известных 25050 известных файлов и каталогов в оригинальном образе мы смогли восстановить inodes для 5755 из них. Since по крайней мере 20257 из 25050 inodes были стерты из их таблиц inode, это означает, что мы потенциально восстанавливаем по крайней мере 963 inodes.

При точном соединении метаданных с содержимым файла мы увеличиваем доказательственную ценность доказательств. Мы не должны использовать только извлечение файлов при поиске файлов в нераспределенном пространстве, если могут быть соответствующие структуры метаданных нераспределенного пространства. Пока структуры метаданных существуют в нераспределенном пространстве, наш универсальный подход временного извлечения метаданных в сочетании с семантическими парсерами может быть использован для соединения метаданных с содержимым файла. Знание контекста файловой системы необходимо для оценки подотчетности соединения между извлеченными метаданными и восстановленным содержимым файла.

При извлечении inodes наш метод имел 100% точность как для оригинального образа Ext4, так и для переформатированного образа. Хотя наш инструмент превосходит коммерческие инструменты в нашей конкретной экспериментальной установке, наш инструмент все еще should рассматриваться как прототип доказательства концепции.

Поддержка файловых систем, отличных от Ext4 и NTFS, оставлена для дальнейшей работы. Автоматизация восстановления файлов возможна, но требует контекстно-зависимых функций. Необходимы дальнейшие исследования, чтобы улучшить точность соединения номера inode Ext4 и имени файла с записью inode, особенно в контексте частично стертых таблиц inode.

Благодарности

Исследование, приводящее к этим результатам, получило финансирование от Исследовательского совета Норвегии по программе IKTPLUSS, в рамках НИОКР проекта "Ars Forensica - Computational Forensics for Large-scale Fraud Detection, Crime Investigation & Prevention", соглашение о гранте 248094/O70.