Восстановление удалённых файлов и файловый карвинг для извлечения утерянной информации

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

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

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

Файловые системы — это то, что управляет этими указателями. От их типа зависит, что именно стирается, а что остаётся. Они делятся на две группы: обычные и журналируемые.

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

Журналируемые (NTFS, ext3/ext4, XFS, Btrfs, ZFS) используют журнал — отдельную структуру для отслеживания операций. Это повышает надёжность, но может затирать данные сразу после удаления, особенно на активных системах.

Как удаляется файл в разных ФС:

Знание структуры ФС — основа восстановления. Именно она определяет, в каком порядке пробовать методы: через метаданные, карвинг или разбор дампа.

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

На уровне ФС метаданные — это записи в системных таблицах:

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

Какие инструменты могут подойти:

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

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

Например, JPEG-файл начинается с FF D8 и заканчивается на FF D9. Когда в дампе видна эта последовательность, можно извлечь файл даже в том случае, если у него нет имени, даты и пути. Так работает большинство утилит для карвинга: они идут по сектору, сканируют сигнатуры, копируют блоки в новый файл.

Карвинг полезен, если:

Что карвинг не может:

Инструменты:

Карвинг — это всегда работа с копией. Перед началом создают образ через ddrescue, dcfldd или guymager. Иначе любой доступ к устройству рискует перезаписать нужные блоки.

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

Для создания образа используют ddrescue. В отличие от dd, он не залипает на битых секторах, ведёт лог и позволяет повторно проходить проблемные области.

Пример создания образа:

Первый проход (-n) собирает всё, что читается без ошибок. Затем можно запустить дополнительный проход с попытками восстановления сбойных секторов:

После получения образа работа ведётся только с ним. Не с оригиналом.

Дальнейшие шаги:

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

С жёсткого диска данные можно восстановить даже через недели, но с SSD и флешками так не работает. В основном это связано с поведением контроллера и поддержкой команды TRIM.

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

На уровне восстановления это означает следующее:

Второй фактор — wear leveling. Чтобы продлить срок службы памяти, SSD и флешки записывают данные не в те же блоки, где были старые, а в новые. Логическая адресация в этом случае не соответствует физической. Это делает невозможным восстановление «по следу», как на HDD.

Еще одним важным моментов является прошивка контроллера. Она полностью определяет, как работает запись, TRIM, резервные области и сборка мусора. Ее поведение закрыто, недокументировано и разное у разных производителей, поэтому восстановление может усложниться так называемым «обскурити».

Практически это значит:

Исключения — отключённый TRIM, отключённая фоновая сборка мусора (редкость), моментальная реакция до активации фоновых процессов.

Если данные действительно важны, а носителем выступает флешка или SSD, правильная тактика:
Шаг 1. Немедленно отключить питание;
Шаг 2. Извлечь устройство и изолировать от перезаписи;
Шаг 3. Работать с побайтовым дампом, но без надежд на успех, если TRIM применился.

При расследованиях это критично. А SSD часто не оставляет следов. Поэтому дополнительно анализируют дампы RAM, shadow copies, кэши и временные файлы на других устройствах.

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

Такая проблема регулярно возникает при работе с бинарными логами бизнес-софта, например, файлами *.lgx или *.dat из кассовых систем, которые используют собственные, закрытые форматы. Аналогичные сложности представляют дампы проприетарных баз данных, таких как Interbase, Firebird или устаревшие Paradox, где данные организованы особым образом. Не менее требовательны к экспертизе файлы телеметрии с SCADA и других промышленных систем, протоколы которых зачастую уникальны для конкретного производителя. Отдельный вызов — это данные из нестандартных контейнеров: будь то зашифрованные образы, архивы с кастомной обвязкой или мультимедийные сборки, где полезная информация надёжно скрыта под слоем неизвестной структуры, не оставляющей следов для стандартного сканирования.

Работа в этом случае требует точного определения сигнатур. Делается это вручную.

Определение сигнатуры

1. Берётся минимум два файла нужного формата, желательно разных размеров.

2. Открываются в hex-редакторе — 010 Editor, HxD, bless.

3. Сравниваются начала (magic header) и окончания, фиксируются повторяющиеся участки.

4. Выделяются характерные последовательности — 4–8 байт, которые совпадают на всех файлах. Это может быть заголовок, флаг версии, фиксированный маркер, padding.

Пример: бинарные файлы логов проприетарной SCADA-системы начинаются с 53 43 44 4C (SCDL), а заканчиваются FF FF. По этим признакам можно вытащить их из диска даже после форматирования.

Scalpel — форк Foremost, работает быстрее, гибче, поддерживает настройку шаблонов в scalpel.conf. Конфигурация строится по схеме:

Пример для описанного выше формата:

Это правило извлечёт файлы с сигнатурой SCDL, не длиннее 500 КБ, заканчивающиеся FF FF. Можно использовать только начало:

Если конец не фиксирован, Scalpel просто будет резать по размеру.

Более старый, менее гибкий, но простой в использовании. Работает по шаблонам из /etc/foremost.conf.

Пример секции:

После настройки запускается:

Foremost извлечёт всё, что подходит под шаблоны, и сохранит по типам в каталоге.

После карвинга получаются десятки, иногда сотни файлов. Их нужно проверять:

Если файл бинарный, но содержит текст — можно фильтровать strings, xxd, grep, чтобы исключить мусор.

Писать парсер вручную следует в следующих случаях:

Можно использовать Python (модуль construct, bitstring), binwalk для автодетекта, или Ghidra/IDA, если есть бинарь, который пишет эти файлы.

Когда носитель начинает сыпаться, считывание начинает происходить нестабильно, возникают ошибки чтения, появляются плохие сектора, поэтому восстановление данных требует другой тактики. Стандартные средства на такие диски лучше не запускать. Любая попытка “просто скопировать” может добить устройство окончательно. В этом случае правильный подход — это работа с образом, снятым в щадящем режиме. Для этого используют ddrescue.

Этот инструмент:

Команды:

1. Первый проход, без повторов:

2. Повторный проход с восстановлением сбойных блоков:

Если диск физически умирает (кликает, пропадает), желательно:

После снятия образа работа продолжается с файлом image.dd, а не с оригинальным диском. Что можно сделать дальше:

Даже если часть образа не читается, ddrescue позволяет достать максимум. В лог-файле видно, сколько байт восстановлено, сколько потеряно, где повреждения. В том случае, если ни одна программа не видит файлов — есть смысл запускать поблочный просмотр (hexdump, bless, wxHexEditor) и искать фрагменты вручную.

Когда речь идёт не об одном документе, а о терабайтах данных — вручную не справиться. Особенно если задача не просто восстановить файл, а найти в образе артефакты: логины, переписку, номера карт, email-адреса. Для таких задач используются инструменты, которые разбирают образ побайтно и вытаскивают данные по шаблонам.

Один из ключевых — bulk_extractor.

Эта утилита:

Пример запуска:

Ключи -x отключают модули, если они не нужны. Это ускоряет обработку.

На выходе — десятки файлов: email.txt, url.txt, ccn.txt и др. Внутри — найденные строки и их смещения. Можно автоматически парсить, фильтровать, сопоставлять с другими источниками.

Если нужно распараллеливание — bulk_extractor поддерживает BEViewer, а также может запускаться через GNU Parallel по частям образа, нарезанного секторовыми смещениями. Дополнительно применяются следующие инструменты:

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

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

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

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

Не менее критично правильно монтировать разделы. Подключение тома в режиме записи может спровоцировать фоновые процессы ОС (например, журналирование, индексацию или обновление метаданных), что способно инициировать разрушительную запись. Работа должна вестись исключительно в режиме read-only, предпочтительно через live-систему или заранее созданный образ носителя.

Современные SSD-накопители, поддерживающие команду TRIM, представляют отдельную проблему: удалённые данные могут быть физически очищены контроллером практически мгновенно, и этот процесс необратим. Отключение TRIM постфактум не имеет смысла — защита от такого сценария возможна только при заблаговременной настройке, что редко достижимо в реальности.

Особая осторожность требуется при работе с повреждёнными носителями. Попытка обратиться к деградирующему HDD через стандартный интерфейс может окончательно вывести его из строя из-за усугубления механических дефектов. Единственно допустимый метод — создание посекторной копии с помощью инструментов вроде ddrescue в пассивном режиме.

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

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

Наконец, аппаратные RAID-массивы требуют особого подхода. Снятие образа с отдельного диска такого массива бессмысленно — без учёта конфигурации контроллера данные будут нечитаемы. В первую очередь необходимо восстановить логическую структуру всего массива, и только затем приступать к извлечению файлов.

Восстановление — не момент «после». Это часть процесса, которая начинается сразу после инцидента. Чем быстрее отключено питание, извлечён диск, создан образ — тем выше шанс получить нужные данные.

Помните, что удаление файла — не конец. Если знать, как работает файловая система, какие данные остаются на носителе и что делает контроллер, можно восстановить многое, но не всё.

Метаданные дают шанс восстановить файл с именем и структурой. Если они уничтожены, то остаётся карвинг. Если накопителем является SSD с TRIM, или файл был зашифрован, то восстановление становится невозможным. Если диск умирает, но образ снят через ddrescue, данные ещё можно вытащить. Если вы сначала монтируете его в rw — нет.

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

И главное — восстановление не заменяет резервное копирование. Ни TestDisk, ни Scalpel, ни bulk_extractor не дадут гарантию. Не забывайте про регулярные бэкапы, зашифрованное хранение и отказ от флешек как основного носителя.