» Восстановление разделов и информации на HDD (часть 8)

temp9285


Цитата:

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

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

А вот парсер чего-то дает пустые файлы...

И можно про ранлист поподробнее ?

avtandil33
http://rghost.ru/7l8F8fnfG/image.png
Речь о выделенной записи, номер которой 61?
С таким номером, она вполне очевидно очень быстро перезаписалась, т.к. перезапись свободных записей начинается с начала MFT.

Парсер запускал от имени администратора?
В принципе, я про парсер то узнал благодаря твоему случаю так что сам с ним мало знаком.
Что касается дампов, то вторая часть в начале имеет характерную сигнатуру индексов, хотя содержимое не очень похоже. Да и по скриншоту карты кластеров есть непонятности. Обычно, если файл из нескольких фрагментов, то в конце первого фрагмента виднеется знак "больше".
Ранлист - это список фрагментов. Перейди в запись MFT под номером 82, в ней будет атрибут 0x80:$J $DATA. Наводишь на него курсор и нажимаешь пробел - вот там и увидишь ранлист.

Кстати, dmde мне подсказал как можно его программой считать файл.
Сейчас к оригиналу его текста доступа нет, поэтому по памяти (и проверил в виртуалке).
Открываешь том, делаешь виртуальную реконструкцию, затем переходишь в папку метаданных.
Находишь нужный тебе, в контекстном меню - Открыть в дисковом редакторе (или просто нажав энтер). Находясь в окне дискового редактора (нижнее справа) выбираешь Правка-Выделить всё.
Затем Сервис-Копировать секторы; в Источнике жмёшь пимпу Редактор - в приёмнике файл.

Добавлено:
По журналу видно что файл удалён 24 числа, потом есть записи от 26-го, а 28-го в 61-ю запись прописался какой то Rotate8.ico
https://www.sendspace.com/file/sayqbh

temp9285

Цитата:

PS. Если хочешь убедиться окончательно в невозможности восстановления в нормальном виде - сделай дамп секторов 267739322+10 и выложи лог Полного сканирования на участке проблемного раздела.

Извини, на работе, не сразу прочитал.
Вот выложил дамп и лог (если правильно сделал ):
https://cloud.mail.ru/public/288nNs3iJamD/HDD/

dmkov9
Дамп правильно и в нём видны 0000.
Хотя я чуть ошибся и запросил то, где явно должны быть нули - нужен дамп зеркала чтобы посмотреть где точно располагалась MFT - 437907802+10
А вот поиск неправильный - нужно сканировать весь раздел, а не 10 секторов.
Кстати, посмотрел - на 160 гиговом разделе одна FAT-таблица имеет размер 20 мегабайт (но их две). А MFT у тебя была 8 мегабайт. Так что без вариантов она занулена. Был бы вариант ели бы она была фрагментирована, но в таком случае не было бы сообщения об отсутствии практически всех записей.

temp9285
Вот дапм https://cloud.mail.ru/public/288nNs3iJamD/HDD/
А сканирование запустил... Чтобы уже быть уверенным

dmkov9
Всё как и ожидалось.
Кстати, на хоботе не трать время Yatagan-а - дай если что ссылку на эту тему.

temp9285
Ну все же https://cloud.mail.ru/public/288nNs3iJamD/HDD/
Добавил туда сканирование.
Ну хорошо. А можно как то найти файлы шрифтов (.otf) и ависинта (.avs) ?

dmkov9
Как и было понятно изначально - MFT улетела в компьютерную нирвану.
Что касается нужных тебе файлов - то это нужно изучать их структуру; есть ли характерные фрагменты, какие то контрольные значения (длина файла, контрольная сумма) и т.п.

temp9285
файлы шрифтов (.otf) попытаюсь глянуть, он по идее может что то писать. А вот с ависинтом сложнее...

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

BOBAH4IK
Насколько я знаю, в индексах есть имя файла, его размер и номер записи MFT.
И как эти данные могут помочь если нет ранлистов (тем более если файлы фрагментированы)?

dmkov9

Цитата:

файлы шрифтов (.otf) попытаюсь глянуть, он по идее может что то писать.

Шрифт что то пишет?
Вообще то я имел в виду другое.
Из http://open-file.ru/types/otf

Информация о заголовке файла HEX: 4F 54 54 4F 00 ASCII: OTTO
Получается что заголовок файла найти можно.
Теперь вопрос в том, есть ли в файле данные о размере или есть ли сигнатура конца файла.
Но это актуально для нефрагментированных файлов.


Цитата:

А вот с ависинтом сложнее...

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

temp9285
Вы опираетесь на свои знания и даете рекомендации согласно им. Я тоже. Для вас это хобби. Для меня - хлеб.

BOBAH4IK
Я не собираюсь узнавать рецепт вашего хлеба. Интересует есть ли он на самом деле?
Потому как не так давно был пример того что DE (трактор) не находит файлов, которые на самом деле есть, или показывает отрицательные значения ранлистов, ну и ещё кое что.
Просто чтобы не получилось что человек поверит что есть шанс, а окажется что его нет.

temp9285

Цитата:

Интересует есть ли он на самом деле?

Как показывает практика, то определенно есть.

Цитата:

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

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

BOBAH4IK

Цитата:

Как показывает практика, то определенно есть.

Поверю на слово.

Цитата:

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

Он был в руках одного из известных участников этого (и не только) форумов.

temp9285

Цитата:

Он был в руках одного из известных участников этого (и не только) форумов.

На 9-й странице данной ветки я уже написал свое мнение по подобному поводу.

temp9285, я опять к Вам (если примите).

Внезапно USB-накопитель попросился отформатироваться:



Как восстановить работоспособность накопителя я знаю (согласиться на форматирование), а вот как восстановить ФС и как следствие информацию - увы, нет.

Помогите, пожалуйста...

P.S. Понимаю, что тема не про USB, но всё же решил вдруг здесь можно что-то сделать.

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

The_Immortal
Я разве кого то, когда то выгонял?
Здесь есть тема по поводу восстановления с USB-носителей? В плане логики, а не физики?
Если рассматривать восстановление файловой системы на уровне логики, то нет особой разницы какой носитель. Хотя оговорки есть, например в случае SSD с их "фишкой" оптимизации равномерного износа.

Внезапно? Или были какие то предпосылки?
Если внезапно, да и вообще - нелишним будет сделать посекторку; тем более обьёмы по нынешним временам мизЕрные.
А далее Полное сканирование с отметкой имевшейся ФС или всех возможных, если нет убеждённости в наличии какой то.
Если же исходить из версии FAT32, то тебе стоит изучить случай insight81 - возможно что у тебя что то подобное (по крайней мере бутсектор и его копия не найдены).

BOBAH4IK

Цитата:

На 9-й странице данной ветки я уже написал свое мнение по подобному поводу.

Спасибо!
Хотелось бы всё таки уточнить.
Нередко, восстановление с использованием комплекса, делается дисков с повреждениями, не позволяющими вычитать поляну. Если она вычитана, то очень велика вероятность что поляна достоверна, по крайней мере в части вычитанного. В этом случае извесно и где расположен битмап и прочая необходимая инфа. Но если подобных данных нет, и уж тем более если они переписаны, то как же можно определить расположение файла не имеющего возможность контроля его целостности.
Поэтому прежненаписанное перефразирую словами песни "Я тебе, конечно верю! Разве могут быть сомненья? ...."

temp9285
Чуть выше я уже дал исчерпывающий ответ.

temp9285,
Цитата:

Здесь есть тема по поводу восстановления с USB-носителей? В плане логики, а не физики?

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

Если рассматривать восстановление файловой системы на уровне логики, то нет особой разницы какой носитель

Цитата:

Внезапно? Или были какие то предпосылки?

Честно говоря, я не договорил Предпосылки были. Это происходит уже раз в 5-ый, причем предыдущие 4 раза не заставляли себя ждать. Казалось бы 4-х раз достаточно, чтобы сменить флешку, но дело в том, что меня флешка очень устраивает по скоростным характеристикам и пока на аналог я не созрел. В связи с этим я довольно часто бэкапился, но после 4-го раза мне это дело (форматирование с последующем восстановлением информации) надоело и я задался вопросом как это дело вылечить. И в какой спец. теме по флешкам наткнулся на совет про форматирование через HP USB Disk Storage Format Tool - мол это решит проблему, т.к. проблема эта логическая. И действительно, о проблеме после этого я забыл на прилично время, но... До вчерашнего вечера =/ Последний бэкап был сделан достаточно давно, поэтому информация важна имеется. Да и честно сказать, хотелось бы просто научиться решать этот цикличный глюк, потому как флешка (за исключением данной неприятности) вполне хорошо работает (знаю, звучит смешно) А та самая важная инфа после полного сканирования восстанавливается без проблем:

Но всё же хотелось бы вернуть раздел на место...

Цитата:

Если же исходить из версии FAT32, то тебе стоит изучить случай insight81 - возможно что у тебя что то подобное (по крайней мере бутсектор и его копия не найдены).

Начал изучать этот случай, но у товарища слетела ФС (RAW), а у меня она, судя по Свойствам диска, есть (FAT32)

The_Immortal
В случае "товарища" неизвестно что в свойствах диска, а RAW фигурирует при проверке чекдиском.
Да и тот случай, как пример был в плане того что и у тебя отсутствует бутсектор, то есть его нет в 63-ем секторе, как прописано в РТ, но ведь он может и быть, но с каким то сдвигом. И, если исходить из моих "познаний" в части работы DMDE с FAT - файловая таблица вроде бы есть, но она как бы принадлежит тому с началом в секторе 2646. Но это может быть моей неверной трактовкой, а проверить в виртуалке сейчас возможности нет.
Так что, если хочешь, сразу сбрось дамп секторов 60+100 и 2646+100; и делай сканирование, выкладывай лог, смотри что найдено и сообщай что там.

BOBAH4IK

Цитата:

Чуть выше я уже дал исчерпывающий ответ.

Ну что же, перечитав ещё раз "исчерпывающий" ответ и проконсультировавшись у более (чем я) разбирающего в устройстве ФС, всё таки усомнился. Точнее, дело не в сомнениях а в сути "рецепта".


Цитата:

Цепочки с данными получившегося массива исключаются из дальнейшего анализа.

Любые данные на разделе, в том числе и служебные, могут быть фрагментированы. Поэтому можно говорить об уцелевших индексах, но не факт что полностью.
К тому же, учитывая не очень характерное смещение MFT, при этом удалённое расположение зеркала. можно предположить что были какие то изменения раздела - возможно небольшая подрезка начала. Поэтому нельзя исключать версию наличия артефатков старых структур.
В любом случае, на выходе получаем некий список файлов с их размерами.
Исходя из результатов сигнатурного восстановления (*) можно сопоставить размеры и приближённо получить имена файлов и сгруппировать по папкам. Но ту есть минимум два момента: бывает что:
- некоторые файлы имеют одинаковый размер. Как в этом случае определить какой из них
- некоторые типы файлов могут иметь различное содержимое, но при этом изначально иметь одни и тот же размер.
То есть, в обоих случаях нельзя быть уверенным в точности соответствия имени файла и найденного если по содержимому нельзя это сопоставить.
К тому же, не все типы файлов имеют возможность контроля его целостности. И может быть вполне реальная ситуация, когда имеется большой видеофайл (нередко фрагментированный) в который вклинился другой тип файла (или один из его фрагментов). Даже при просмотре всего файла может быть трудно вычислить вкрапление, и не факт что его не было до всего этого. Соответственно, нет гарантии что из исследования будет исключен нужный в дальнейшем фрагмент.


Цитата:

По оставшемуся объему производится сигнатурный поиск по нужным регулярным выражениям.

Если нет MFT то остаётся вариант сигнатурного поиска. И он актуален (почти 100%) для нефрагментированных файлов. И если уже был результат (*) такового, то что изменится если даже будет исключена "занятая " зона?
Предполагается каверинг из оставшихся лоскутков? Это умеет делать не оглашённое. но вполне предполагаемое ПО?

В общем то, рецепт имеет какой то смысл, но только в реализации он достаточно малоэффективен (ИМХО). И это при том, что есть ещё и другие "мелочи". Или смысл этого рецепта в одном - берите денежки и идите к "пекарям"? А какова будет стоимость такой вот "булки" (если она испечётся)?

PS. Статьи по вопросам восстановления данных на сайте, указанном в профиле, написаны кем?

temp9285


Цитата:

Речь о выделенной записи, номер которой 61?
С таким номером, она вполне очевидно очень быстро перезаписалась, т.к. перезапись свободных записей начинается с начала MFT.

Ну да, оно самое.


Цитата:

Парсер запускал от имени администратора?

.

Ну да, я все время под админом работаю


Цитата:

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

НУ вот почему-то так показывал DMDE.


Цитата:

Ранлист - это список фрагментов. Перейди в запись MFT под номером 82, в ней будет атрибут 0x80:$J $DATA. Наводишь на него курсор и нажимаешь пробел - вот там и увидишь ранлист.

Кстати, dmde мне подсказал как можно его программой считать файл.
Сейчас к оригиналу его текста доступа нет, поэтому по памяти (и проверил в виртуалке).
Открываешь том, делаешь виртуальную реконструкцию, затем переходишь в папку метаданных.
Находишь нужный тебе, в контекстном меню - Открыть в дисковом редакторе (или просто нажав энтер). Находясь в окне дискового редактора (нижнее справа) выбираешь Правка-Выделить всё.
Затем Сервис-Копировать секторы; в Источнике жмёшь пимпу Редактор - в приёмнике файл.

Ясно, спасибо за инфо.


Цитата:

По журналу видно что файл удалён 24 числа, потом есть записи от 26-го, а 28-го в 61-ю запись прописался какой то Rotate8.ico

Ну тогда судя по всему - оба случая в морг... Что ж - по крайней мере обогатился знаниями, так что все равно спасибо !

avtandil33

Цитата:

Ну да, я все время под админом работаю

Даже в учётной записи с админскими правами, некоторые задачи надо запускать от имени администратора.


Цитата:

НУ вот почему-то так показывал DMDE.

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


Цитата:

Ну тогда судя по всему - оба случая в морг...

Возможно, но я писал про сигнатурный поиск. В силу того что образы чаще всего огромные, что обычно предполагает фрагментацию, тем не менее может он был нефрагментирован и на его поляну ничего нового не записалось? Хотя шанс такого везения очень низок, а может быть и нулевой.
Да и вон, выше, выясняется что есть ПО, которое может (?) творить чудеса - может и правда?

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

Нужна инфа. Хард после глюка пустой. Клиент сказал что ничего не надо. Была установлена 7-ка. На разделы не разбит. Оказалось инфа нужна. Есть подозрение что стояла 8-ка на GPT. Чем проверить был ли GPT раздел. Пока сканирую в GetBack. В DMDE еще не сканировал.

ravbubu

Цитата:

Чем проверить был ли GPT раздел.

GPT это не раздел а стиль разметки и нет особого смысла определять какой тип был раньше.
Если же так сильно хочется - посмотреть содержимое штук 100 секторов начиная с LBA1 и столько же в конце диска (кроме последнего). Но, если для перевода из GPT в MBR использовалась описываемая в интернетах метода, то clean занулил эи сектора.

Прогнал DMDE вышло куча томов. Почему столько NTFS разделов?

ravbubu
Будем гадать или подождём телепатов?

Пока восстанавливаю через GetBack. С DMDE позже разберусь.