Люди, стремясь к комфортным условиям работы, зачастую не задумываются о сохранности и защищенности своих данных и рано или поздно сталкиваются с проблемами их утраты.
Рассмотрим запрос клиента USB Флэшка Трансценд 2Гб.
Со слов клиента, однажды при установке накопителя в USB-порт компьютера было предложено его отформатировать.
По словам клиента, он отказался от этого и обратился за помощью к системному администратору.
Системный администратор, обнаружив, что компьютер зависает при подключении USB-накопителя, не смог придумать ничего лучшего, как согласиться с предложением операционной системы отформатировать его ( никогда не делай этого! ).
Далее системный администратор воспользовался популярной программой автоматического восстановления R-Studio. Результат ее работы в виде безымянных папок был скопирован клиенту на другой диск.
При просмотре результата клиент обнаружил, что около четверти файлов невозможно открыть и, что самое ужасное, 1С Бухгалтерия 7.7 отказалась запускаться с восстановленной базой данных, сославшись на отсутствие файлов.
рис.
1 Как выяснилось, резервной копии этой базы данных у клиента было больше года.
Первым этапом решения подобных задач является создание поблочной копии исходного накопителя (или, как принято писать со времён, когда носителями информации были только флоппи- и жёсткие магнитные диски, посекторной ).
При вычитании обнаруживается нестабильная скорость чтения, что свидетельствует о серьёзном износе И-НЕ-памяти (многократное чтение И-НЕ контроллером страниц И-НЕ-памяти и исправление ошибок за счёт избыточности кодов исправления ошибок ( ЕСС ) — очень ресурсоемкая операция, что в конечном итоге влияет на скорость чтения).
Если есть непрочитанные разделы, необходимо заполнить их по шаблону, который в дальнейшем поможет нам идентифицировать файлы, которые не были прочитаны полностью.
Далее переходим к анализу.
Необходимо установить, какая файловая система и в каких границах была ранее на флешке.
То есть необходимо искать регулярные выражения, специфичные для различных метаданных файловой системы, но прежде чем начать, давайте проверим простой вариант, предполагающий, что границы разделов одинаковы.
Для этого установите текущие параметры файловой системы.
Открытие ЛБА 0 (0x0 в файле образа) и проверьте там наличие таблицы разделов, либо наличие Boot-сектора файловой системы.
рис.
2 В нашем случае мы видим по смещению 0x1C2 тип раздела 0x0B, а это значит, что на данный момент на USB-накопителе имеется раздел FAT32, который начинается с сектора 0x80 (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов ( DWORD по смещению 0x1CA).
Заходим в загрузочный сектор описываемого раздела в сектор 0x80 (в файле образа байты 0x10000) 
рис.
3 Необходимо вычислить начальную точку, то есть расположение нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.
Для этого нам потребуются следующие параметры, описанные в загрузочном секторе (будут указаны как смещение от начала сектора): размер сектора по смещению 0x0B - 0x200 (512 байт), количество секторов в кластере по смещению 0x0D. - 0x08, размер кластера получается умножением размера секторов на количество секторов в кластере 0x08*0x0200=0x1000 (4096 байт), количество зарезервированных секторов до первой копии таблиц ТОЛСТЫЙ - по смещению 0x0E=0x01FE (510 секторов), количество копий FAT - по смещению 0x10=0x02, размер одной копии FAT - по смещению 0x24=00000F01 (3841 сектор).
Используя полученные параметры, рассчитаем положение начала области данных: 0x10000+0x01FE*200+0x00000F01*2*200=0x410000 (сектор 8320).
Небольшой подвох от создателей FAT32 заключается в том, что на данный момент мы вычислили начало области данных для раздела FAT32, но оно не является нулевой точкой отсчета, так как первые две записи в таблице FAT зарезервированы и не являются используются по назначению, и поэтому нулевая точка — это начало области данных минус 2 кластера.
В данном случае это будет 0x410000-0x1000*2=0x40E000 (сектор 8318).
Мы проверим отсутствие записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет расхождений.
Рис.
4 Сравнение копий FAT показало, что расхождений нет. Анализ содержимого одной из копий FAT показал, что, согласно таблице, на разделе заполнен только один кластер.
Далее вам необходимо оценить корневой каталог на наличие удаленных записей.
Положение первого кластера корневого каталога указывается в загрузочном секторе по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.
рис.
5 По рассчитанному выше адресу мы видим корневой каталог (корневой каталог), который содержит одну 32-байтовую запись.
По смещению 0x0B мы видим значение 0x08, которое указывает тип записи — метку тома.
Тот факт, что таблицы размещения файлов заполнены нулями, а в корневом каталоге нет и намека на какие-либо другие записи, говорит о том, что данный раздел был отформатирован.
Чтобы проверить предположение о том, что раздел не пересоздан и все параметры файловой системы верны, нужно выполнить поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (это выражение является признаком начало каталога FAT32).
рис.
6 При поиске регулярного выражения необходимо убедиться, что это действительно каталог, исходя из других критериев, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом каталога.
По информации рис.
6 можно сказать, что этот каталог начинался с кластера 3 (номер текущего кластера каталога DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть) ) и был описан в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительского каталога).
Проверим, соответствует ли номер кластера этого каталога нулевой точке отсчета файловой системы, созданной после форматирования.
Для этого умножьте номер кластера каталогов на размер текущего кластера и прибавьте к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видите, платежный адрес соответствует фактическому местоположению.
Установка имени этого каталога возможна только в том случае, если корневой каталог ранее состоял более чем из одного кластера, и ссылка на этот каталог находилась не в первом кластере, так как при форматировании содержимое первого кластера было полностью уничтожено вместе с таблицы размещения файлов.
Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20. 
рис.
7 Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Опять видим, что позиция каталога соответствует параметрам текущей файловой системы.
Но, кроме этого, мы видим, что имеется номер кластера родительского каталога 0x03, что указывает на то, что этот каталог был вложенным, и глядя на рис.
6, можно установить имя каталога, которое показано на рис.
7. Итак, согласно рис.
6, по смещению 0x4B мы видим значение 0x10 — это означает, что данная запись указывает на каталог, а по смещениям 0x5A и 0x54 число 0x00000004 — это указатель на 4-й кластер.
По смещению 0x40 – имя каталога «BIN».
Так устанавливается взаимосвязь каталогов в поврежденном разделе FAT. Выполнив определенное количество проверок каталогов в разных частях образа, мы можем сделать окончательный вывод о том, что данный диск был отформатирован в границах предыдущей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей.
, то есть дальнейшие аналитические операции необходимо проводить внутри раздела.
описан в таблице разделов с учетом параметров текущей файловой системы.
Зная, что база данных 1С, состоящая из DBF-файлов, должна содержать файл конфигурации 1CV7.MD, будем искать последовательность 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять внутри 32-байтовых блоков с нулевым смещением.
Рис.
8 Таким образом, мы находим все каталоги, содержащие указатель на файл 1CV7.MD. В нашем случае был найден только один такой каталог, что говорит о том, что мы нашли первый кластер нужного каталога.
Далее следует анализ положения родительских каталогов, вплоть до корневого каталога.
Каждый найденный каталог регистрируется в таблице FAT (сначала как каталог из одного кластера, записывая FF FF FF 0F для соответствующего элемента таблицы).
Ссылка на дочерний объект также записывается в корневой каталог.
На данном этапе мы будем копировать найденные файлы в предположении их непрерывности, так как обе копии FAT не содержат информации о фрагментации (помним, что они были безвозвратно уничтожены системным администратором в результате бездумного форматирования флешки).
).
После копирования каталога базы данных 1С анализируем количество файлов.
Учитывая, что фрагмент каталога был размером с один кластер, мы извлекли не более 126 файлов, что явно намного меньше того, что должно быть в каталоге с файлами DBF и CDX, относящимся к базе данных 1С.
Программы автоматического восстановления дадут примерно такой же результат, о чем свидетельствует результат, полученный системным администратором с помощью R-Studio. Извлеченные файлы включают 1CV7.MD (файл конфигурации) и 1CV7.DD (файл словаря данных).
После выполнения проверки целостности мы создадим на нашем диске временную папку, куда поместим 1CV7.MD. Этот путь мы укажем при добавлении новой базы и откроем конфигуратор, через который на основе этой конфигурации создадим чистую базу данных.
Сравним сгенерированный файл DD с восстановленным; если описания и количество каталогов идентичны, то никаких дополнительных действий не требуется и, имея полный список файлов, можно приступить к поиску остальных фрагментов каталога базы данных 1С.
Для этого вам необходимо выполнить поиск последовательности кодов символов ASCII, используемых в именах недостающих файлов DBF. По мере обнаружения фрагментов каталога добавлять продолжение цепочки в таблицу размещения файлов.
После каждой операции добавления цепочки каталогов копируйте файлы и анализируйте, насколько сократилось количество недостающих DBF-файлов, и снова формируйте последовательность кодов символов ASCII для поиска следующего фрагмента.
рис.
9 Также необходимо помнить, что при записи цепочки фрагментов каталога в таблицу размещения файлов необходимо анализировать фрагменты на предмет их соответствия друг другу.
ЛФН записи.
В случае коротких записей цепочку можно записать с любым порядком фрагментов.
В данном случае после поиска 5 последовательностей нам удалось найти все оставшиеся фрагменты каталога с базой данных 1С.
После того, как полная цепочка фрагментов каталогов построена, повторно копируем все файлы базы данных 1С с условием их непрерывности.
Информация о пользователе содержится в файлах DBF, поэтому необходимо проверять их целостность.
Основным методом контроля целостности DBF-файла является проверка информации, содержащейся в служебном заголовке, и соответствие содержимого файла описанию в заголовке.
рис.
10 Первоначально оценивается заголовок: проверяется его длина, указанная по смещению 0x08, на предмет, ведет ли указанное в нем смещение к маркеру конца 0x0D. Записи базового поля, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых имя поля следует по смещению 0x00, тип поля — по смещению 0x0B, а размер поля — по смещению 0x10. Сумма размеров полей +1 (один дополнительный байт на каждую запись в базе данных — это статус записи в DBF) должна равняться содержимому по смещению 0x0A (размеру одной записи в базе данных).
На картинке DBF-файлов мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A. Давайте проверим, правильный ли размер файла.
Для этого умножаем количество записей, указанное в заголовке по смещению 0x04, на размер одной записи в базе данных по смещению 0x0A с последующим сложением с содержимым по смещению 0x08.
0x00000003*0x005A+0xE1=0x01EF. Результирующее смещение должно содержать маркер конца файла 0x1A.
Для контроля целостности содержимого полей можно использовать визуальный метод. 
рис.
одиннадцать В этом варианте просмотра вам необходимо пролистывать содержимое постов от начала до конца.
Если заполнение однородное, каждое поле содержит типы данных, характерные для описанного в шапке и отсутствует посторонний контент, то после просмотра DBF-файла можно сделать вывод о корректности его содержимого.
При обнаружении контента, не соответствующего описанию поля в заголовке базы данных, необходимо установить точное место начала неверных данных.
Рис.
12 На основе описания полей в заголовке и содержимого конкретного DBF-файла можно сгенерировать ориентировочные ASCII-последовательности, которые должны располагаться по заданным смещениям в недостающих фрагментах.
Если на одном из дисков нет однотипных баз данных (в том числе файловых копий этой же базы), этот метод позволит относительно быстро найти все недостающие фрагменты в образе диска.
Отдельно отметим, что дополнительные трудности при объединении фрагментов возникнут, если размер записи в DBF-файле мал или кратен 16. При наличии других баз данных того же типа задача усложнится в разы (данное утверждение актуально на всех этапах работы, начиная с поиска фрагментов нужного каталога).
Необходимо проверить целостность каждого DBF-файла, которых в одной базе 1С несколько сотен.
После прохождения всех проверок и сбора фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятие.
рис.
13 В идеале по результатам тестирования все пункты, отмеченные галочками, должны пройти успешно.
Если обнаружены ошибки в первых двух пунктах, то необходимо проанализировать журнал ошибок в конфигураторе и выяснить, какие DBF-файлы содержат посторонние данные, не обнаруженные при проверках.
Если при проверке логической целостности обнаружены ошибки, то снова необходимо проанализировать журнал ошибок, чтобы выяснить, кроется ли проблема с базой данных в качестве ее сбора, или в ошибках, допущенных разработчиками конфигурации 1С.
Обратим внимание на то, что если бы данная флешка не была отформатирована, то после ее корректуры процедура восстановления данных была бы намного проще, что значительно сократило бы стоимость и сроки выполнения работ. В заключение хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубят проблему, а также пожелать чаще выполнять операции резервного копирования.
Следующая публикация: Восстановление файлов после трояна-вымогателя Предыдущая запись: Восстановление данных с поврежденного массива RAID 50 Теги: #Резервное копирование #Администрирование баз данных #Восстановление данных #1c #usb #бухгалтерия #flash #форматирование #форматирование #база данных #флешка #флешка #fat32 #DBF
-
Внедрение Dynamics Ax В Глобальной Логистике
19 Oct, 24 -
Диаграммы Фейнмана В Первом Классе.
19 Oct, 24 -
Легко Получить Подписчиков
19 Oct, 24 -
Usb 3.0 Уже Здесь
19 Oct, 24 -
Любимые Игры Российских It-Боссов
19 Oct, 24 -
Где Найти Рекламодателя Для Стартапа?
19 Oct, 24
