HDD для Mac или заурядный случай для лаборатории восстановления данных

К нам на диагностику поступил накопитель Seagate ST4000DM000 семейства Lombard. Со слов клиента можно было понять, что накопитель использовался на компьютере Apple Macintosh и был на нем отформатирован, и не один раз, за все время эксплуатации. Вопросы касательно состояния накопителя или типа файловой системы остаются без ответа. Клиентом дается лишь сбивчивое пояснение, что необходимо восстановление файлов с оригинальной структурой каталогов. Также клиент уточняет, что в одном из сервисов были получены файлы без оригинальных имен с помощью какой-то программы восстановления данных, но его такой результат не устраивает.





Приступая к диагностике, первым делом необходимо оценить состояние накопителя. Так как это Seagate, то нам необходимо увидеть терминальный лог с момента подачи питания, S.M.A.R.T. и оценить способность чтения головок в зонах разной плотности. Как правило, такой коротенький тест позволяет выявить многие неисправности.

Подключаем, подаем питание. В терминале накопитель кратко сообщает, что процедура старта прошла успешно, и по регистрам DRD и DSC демонстрирует готовность к принятию команд.


Рис. 2 Терминальный лог старта HDD Seagate ST4000DM000

Следом необходимо проверить показания S.M.A.R.T. (что такое SMART и на что в нем обращать внимание я уже описывал в своей заметке).

Рис. 3 Показания S.M.A.R.T.

Первое, что мы смотрим, так это время наработки (атрибут 0х09), так как если окажется, что оно близкое к нулевому значению, то нет смысла обращать внимание на показания S.M.A.R.T., поскольку будет высока вероятность, что статистика кем-то была сброшена технологическими командами, и текущие показания не показывают всех событий, зафиксированных за время работы накопителя. В нашем случае время наработки 3 696 часов, что свидетельствует о том, что скорее всего в показания S.M.A.R.T. вмешательства не было.

Далее обращаем внимание на показания атрибутов 0х05, 0хС5 (197), 0хС6 (196) в столбце RAW. Нулевые значения свидетельствуют о том, что за время работы накопителем не были зафиксированы серьезные проблемы с чтением с поверхности и никаких переназначений (remap) не выполнялось.
Показание атрибута 0хС7 (199) намекает на возможные проблемы с трансфером данных в высокоскоростных режимах. С учетом того, что количество ошибок невелико, пока не будем делать преждевременных выводов.

Так как это не накопитель с черепичной записью (SMR), то способность чтения всех головок в зонах разной плотности оценить достаточно просто. Для этого достаточно знать количество головок, ориентировочный размер минизон и их порядок чередования в выстраивании логического пространства накопителя. Для демонстрации используем Data Extractor. Построим карту минизон.

Рис. 4 Карта минизон в логическом пространстве Seagate ST4000DM000

Из списка виден порядок использования минизон для выстраивания логического пространства:
0, 1, 2, 3, 4, 5, 6, 7, 7, 6, 5, 4, 3, 2, 1, 0 и далее цикличное повторение. Исходя из размера одной минизоны у данного накопителя, очевидно, что достаточно прочитать несколько участков логического пространства (обычно это начало, середина и конец логического диапазона) протяженностью около 500 000 секторов, чтобы убедиться, что накопитель не зависает и скорость сканирования резко не проседает ни по одной из поверхностей.

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

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

Хочу обратить внимание, что на дисках, где количество секторов больше чем 4 294 967 296 секторов, необходимо использовать GPT, чтобы задействовать всю емкость, так как в классической таблице разделов используются 32-битные величины, разрядности которых недостаточно. В нашем случае ST4000DM000 представляет из себя накопитель емкостью 4Тб, в котором логический диапазон состоит из 7 814 037 168 секторов по 512 байт.

Начнем с просмотра содержимого в LBA 0.

Рис. 5 Таблица разделов описывающая наличие GPT.

Здесь мы обнаруживаем классическую таблицу разделов, с описанием одного тома. По смещению 0x1C2 указан тип раздела 0xEE со смещением 0х00000001 сектор от начала диска и размером 0x3A3817D5.

Назначение этой записи – указать, что все содержимое диска доступное для классической таблицы разделов занято, чтобы различные старые дисковые утилиты, не имеющие понятия о GPT, не могли создать раздел. Но в случае дисков, где количество секторов больше, чем 4 294 967 296, защищенная область должна быть 0xFFFFFFF, а не 0x3A3817D5.

Обращаем внимание, что величина 0x3A3817D5 (976 754 645) приблизительно в 8 раз меньше 7 814 037 168 – общего количества секторов на диске. Это нам позволяет сделать предположение, что вероятнее всего диск использовался как устройств, о размер сектора у которого равен 4096 байт, а не 512 байт. Проверим предположение и попробуем поискать регулярное выражение 0x45 0x46 0x49 0x20 0x50 0x41 0x52 0x54 (EFI PART). Если оно будет в секторе 1, то предположение неверно, если будет в секторе 8, то предположение подтвердится.

Рис. 6 Заголовок GPT

Также проверим, описаны ли какие-либо тома в данной GPT, для чего перейдем к сектору 16

Рис. 7 Разделы описанные в GPT

Здесь обнаруживаются две записи.

Первая запись – это том размером 76 800 (614 400) секторов, где используется файловая система FAT32. Данный том резервируется для EFI нужд.

Вторая запись – это том размером 976 644 858 (7 813 158 864) секторов, где используется файловая система HFS+.

Так как версия с тем, что диск использовался как устройство с размером сектора 4096 байт подтверждена, то следующим шагом будет продолжение анализа с использованием Data Extractor.

После создания задачи меняем параметр размера сектора с 512 на 4096 и получаем следующую картину.

Рис. 8 Параметры HFS+

На диске видим два тома с корректными файловыми системами. Первым том, исходя из роли и размера, нас не интересует. А вот второй том уже представляет интерес.

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

Сканирование CatalogFile+Journal (структур HFS+) показывает, что диск пуст на 99,9% и признаков пользовательских данных, описанных этой файловой системой, нет.

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

Рис. 9 Результат поиска регулярных выражений.

Анализ области около 2Гб, который длится менее 2 минут, показывает нам, что кроме существующих FAT32 и HFS+ в наличии признаки существования тома с файловой системой ExFAT. Первое, что нас интересует, – это просмотр корневого каталога тома (ExFAT Root Directory).

Рис. 10 Корневой каталог ExFAT

Бросается в глаза метка тома «Transcend». Странность в том, что широко распространены внешние диски этого производителя в форм-факторе 2,5 дюйма, а не 3,5. И достаточно невысокая вероятность, что пользователь сам когда-либо решил поставить подобную метку тома.

Выпишем названия директорий, которые описаны в корневом каталоге и зададим вопросы клиенту на предмет того, не они ли являются искомой информацией.

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

В процессе диалога можно предположить, что клиент является курьером организации-посредника на рынке услуг восстановления данных. Дальнейшие переговоры эту версию подтверждают, так как после озвучивания информации клиентом своему менеджеру следует пауза. Видимо менеджер также не в курсе того, что именно должно быть на диске. Но спустя минут 15 клиенту поступает звонок, в котором сообщается, что это именно те данные, которые необходимо извлечь, и что их объем должен быть около 2Тб. Также мы информируемся о том, что нам предоставлена для анализа посекторная копия оригинального носителя, сделанная с помощью WinHex.

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

Для реконструкции ExFAT нам необходимо знать, каким был размер кластера у данной файловой системы, и определить позицию нулевого кластера (точки отсчета). Далее поискать останки таблицы размещения файлов и битовую карту занятого пространства (Bitmap).

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

При анализе первых 2Гб были найдены части директорий ExFAT. Оценив размер этих структур и дальнейшее заполнение нулями до начала иных данных несложно установить размер кластера. После просмотра нескольких директорий видим ярко выраженные интервалы по 256 (2048) секторов. Это позволяет нам предположить, что размер кластера был 1 048 576 (0х100000) байт или 1 Мб.

Для определения начала отсчета посмотрим на позиции близлежащих директорий. Обратимся вновь к рисунку 10. В частности, нас интересует директория «$RECYCLE.BIN», так как она располагается практически в самом начале. Номер ее кластера указан в смещении 0х94 и представляет из себя двойное слово (DW), в котором записано значение 0x00000005, то есть директория расположена в кластере 5. Также обратим внимание на директорию «Ххххххххх Хххх.photoslibrary», которая согласно значения указанного в смещении 0xF4, расположена в кластере 7. Данные директории тем хороши, что там с высокой вероятностью ожидается предсказуемый набор директорий или файлов.

Далее от корневой директории с шагом 0x100000 байт или 256 (2048) секторов полистаем вперед по адресному пространству.

Рис. 11 Директория ExFAT, возможно $RECYCLE.BIN

Содержимое похоже на вариант пустой папки корзины, где кроме файла «desktop.ini» ничего не описано. Расположение файла по смещению 0х34 указывает на кластер 6 и размер 0х81 (129) байт. Перейдем еще на 1 кластер вперед

Рис. 12 Содержимое файла desktop.ini

Содержимое очень похоже на то, что обычно можно увидеть в файлах «desktop.ini» и соответствует размеру 0х81 (129) байт. Есть основания предположить, что на рис.11 папка $RECYCLE.BIN, а на рис. 12 описанный в ней файл. Если предположение верно, то в следующем кластере мы должны увидеть директорию, и ее содержимое, вероятно, должно быть похожим на типичную папку photoslibrary для MacOS на Apple Macintosh.

Рис. 13 Директория ExFAT, возможно ХххххххххХххх.photoslibrary

Как видим, предположение оказалось верным, и мы увидели имена ожидаемых директорий. Количество совпадений на данном участке можно посчитать достаточным и сделать расчет нулевой точки и позиции корневой директории некогда существовавшего тома.
Корневая директория находится в кластере 4. Так как она предшествует директории $RECYCLE.BIN, номер кластера которой 5.

Нулевая точка по отношению к $RECYCLE.BIN должна находится на расстоянии минус 5 кластеров. Позиция $RECYCLE.BIN 37 888 (303 104) сектор. 5 кластеров это 1280 (10 240) секторов. Выполнив простое вычитание получаем искомую позицию: 37 888 (303104) – 1 280 (10240) = 36 608 (292864) или смещение от начала логического пространства в байтах это 292 864 * 512 = 149 946 368 (0x8F00000).

Далее, имея начальную точку отсчета, размер кластера и позицию корневого каталога, попробуем значительно большим числом проверок подтвердить корректность нашего предположения.

Средствами Data Extractor это не так быстро сделать для раздела ExFAT, поэтому монтируем диск в ОС (с запретом записи).

Рис. 14 Меню монтирования дисков в ОС в утилите PC3000 Win 7 Disk

Используем бесплатный Image Explorer от софт-центр, где, открыв диск, мы можем быстро написать параметры виртуальной файловой системы и произвести оценку правильности предположений.

рис. 15 Развернутое древо каталогов ExFAT

Как видим на скриншоте, директории и файлы на своих местах, что позволяет сделать вывод, что параметры файловой системы определены верно.

На этом диагностические мероприятия можно остановить и далее согласовывать с клиентом следующий перечень работ:

1. Поиск регулярных выражений в рамках всего логического пространства для установления возможного расположения различных типов данных.

2. Как минимум реконструкция одного раздела ExFAT.

3. Анализ пересечений с новыми данными, записанными поверх.

4. Построение инвертированной карты по отношению к существующим данным по реконструированной файловой системе в рамках пересечения с Bitmap и поиск пользовательских данных в этих участках с последующей сортировкой найденного.

В случае компаний-посредников, как обычно, начинается перезвон, и лишь только после согласия конечного владельца (который вряд ли подозревает, что его данные будут восстанавливаться в нашей лаборатории) дается согласие на проведение работ.

Любая работа даже с исправными дисками все равно начинается с создания посекторной копии на другой накопитель. Данная мера необходима для того, чтобы накопитель клиента остался в неизменном виде и никакие инициативы ОС не привели к безвозвратному искажению данных. Для диска 4Тб копирование через порты PC3000Express составит около 10-12 часов.

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

Рис. 16 Результат поиска регулярных выражений в границах всего накопителя

По результатам сканирования выясняется, что пользовательских данных на диске однозначно значительно меньше, чем 2Тб, заявленные клиентом. Последнее регулярное выражение находится на 539 877 376 секторе и до конца диска более не встречается ничего похожего на данные пользователя, кроме конечного маркера вновь созданной HFS+, хотя диск до самого конца не в нулях. Вероятно, до того, как на диске был создан раздел ExFAT, этот накопитель содержал шифрованный том. Ничем другим наличие только «шумных» данных не объясняется.

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

Рис. 17 Фрагмент сектора корневой директории ExFAT

По смещению 0х34 указан номер кластера 2 – это позиция битовой карты (Bitmap) на разделе ExFAT. По смещению 0х38 указан размер структуры 0х0746F1 (476 913 байт или 3 815 304 бита). При анализе данной структуры установлено, что возведенные биты в карте есть только для первых 270Гб, а далее, согласно карте, раздел пуст. То есть битовая карта соответствует результатам поиска регулярных выражений, но и то, и другое расходится со словами клиента.

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

1. Действительно ли им была создана полная посекторная копия, которую передали нам для анализа?

2. Действительно ли владелец уверен, что на этом диске было 2Тб данных?

3. И если уверен, то согласен ли на продолжение работ по восстановлению данных зная, что на этом диске не может быть получено данных более 270Гб?

На первый вопрос мы получили ответ посредством удаленного доступа к оригинальному диску. И в дисковом редакторе, пролистав его с некоторым крупным шагом, сравнили с той копией, что у нас. Выяснилось, что копия была полной.

На второй вопрос был передан ответ, что владелец информации считает, что он точно видел, что диск заполнен на 2Тб, но уже не очень в этом уверен.

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

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

Рис. 18 Список найденных директорий ExFAT

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

Также необходимо произвести маркирование всех областей, занятых вновь созданными файловыми структурами. Для этого мы построим карты расположения всех структур и файлов на разделах FAT32 и HFS+.

Рис. 19 Карта структур и данных на томе HFS+

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

Для дальнейшего более удобного использования аналитических инструментов Data Extractor необходимо описать раздел в таблице разделов и создать загрузочный сектор для ExFAT раздела.

Рис. 20 Таблица разделов с прописанным томом ExFAT

По смещению 0x1D2 впишем тип тома 0х07. Данный тип используется как для NTFS так и для ExFAT.
По смещению 0х1D6 указатель на начало тома ExFAT. Пусть это будет 32 сектор (0х20).
По смещению 0х1DA впишем максимально допустимый для классической таблицы разделов размер тома (хоть это значение и меньше реального размера тома, но в данном случае допустимо, так как мы не планируем этот поврежденный том монтировать в какую-либо ОС, и ненулевое значение нам нужно лишь для нормальной работы инструментов Data Extractor).

Рис. 21 Загрузочный сектор ExFAT

Так как Data Extractor весьма чувствителен к содержимому загрузочного сектора ExFAT, то зачастую заполнение только важных полей окажется недостаточным (что не очень логично), и так легко отобразить раздел во внутреннем проводнике, как это было на диагностике в Image Explorer, не получится. Поэтому в случае загрузочного сектора ExFAT лучше взять стандартный шаблон, и в него ввести правильные значения.

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

Заполним поля:
Bytes Per Block – количество байт в секторе. В ExFAT указывается степень, в которую нужно возвести 2, чтобы получить размер.
Block per Cluster – количество секторов кластере. Здесь также указывается степень, в которую нужно возвести 2, чтобы получить количество.
Total Clusters – количество кластеров, доступных на томе. Вписываем значение 3 815 304. Оно получается из умножения размера битовой карты на 8.
Total Blocks – количество секторов. Значение получается из умножения Total Clusters на размер кластера (который, в свою очередь, получается из перемножения Bytes per Block на Blocks per Cluster)
FAT offset – смещение от загрузочного сектора до таблицы размещения файлов. Создадим пустую структуру и положим с сектора 64. Впишем в нее стандартный заголовок.
Block Per FAT – количество секторов, которое занимает FAT таблица. Ее размер несложно посчитать исходя из количества кластеров. Block Per FAT = Total Clusters / (Bytes per Block /4) c дальнейшим округлением до целого в большую сторону. 3 815 304 / (512/4) = 29 807, 0625 = 29 808.
(Как бы ни пытались в некоторых источниках назвать ExFAT 64-битной файловой системой, таблица размещения файлов используется 32-битная, но, в отличие от FAT32, для адресации используются 32 бита, а не 28.)
Number of FATs – количество копий таблиц. К сожалению, при создании разделов оно обычно равно 1.
Cluster Heap Offset – указывается смещение до битовой карты в секторах.
Root Dir Cluster – номер кластера корневой директории.

После того, как раздел стал доступен в проводнике Data Extractor, мы построим карту занятого пространства по битовой карте.

Рис. 22 Карта занятого пространства структурами ExFAT и пользовательскими данными согласно битовой карты.

Также построим карту расположения файлов по существующим файловым записям, отсортируем по порядку расположения файлов на диске и сопоставим с данными битовой карты.

Рис. 23 Фрагмент карты расположения файлов доступных на томе ExFAT

По результатам построения карты расположения файлов наблюдаем достаточно обширную «дыру» в логическом диапазоне с 718 528 до 57 131 008. На битовой карте очевидно, что эта область занята пользовательским данными. Также при поиске регулярных выражений по всему диску в этой области обнаруживались признаки данных.

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

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

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

Рис. 24 Директория с указателями на найденный структуры у которых отсутствует родительский объект.

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

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

По завершении этих операций можно приступить к копированию найденных данных с учетом наличия в карте расположения файла секторов «прочитанных с ошибкой» и таким образом отсеять файлы, которые однозначно перезаписаны новыми данными. Пометки «прочитанных с ошибкой» мы создали после построения карт объектов FAT32 и HFS+.

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

Предыдущая публикация: Самостоятельная диагностика жестких дисков и восстановление данных