» Пропал диск. Восстановление таблицы разделов (не данных) - 2

atdevilru
Шлейф заменили?
Скажу честно: такой длинный ранлист я вкуривать сейчас не буду. Время не резиновое. Я не знаю как на работе можно столько времени уделять восстановлению на форумах. Заморачиваться с этим есть смысл только ради спортивного, а я уже несколько раз подобное делал, когда время было...

9285
Битмэп можете взять любой, приклейте его в конец записи после DATA и поправьте размер файловой записи в заголовке, если нужно (сейчас там 1E0h). Очевидных проблем в ранлисте я не заметил до байтов 7A 08..., где вместо 7A должно быть 00. Но суммарный размер фрагментов не тот (не совпадает с last VCN и размерами в байтах).

bai01
На раздел с атрибутом 20 в MFT забейте. При таком количестве фрагментов in-place вручную вообще нереально. Скопируйте через R-Studio, R-Saver или GetDataBack for NTFS.

Antech
Странно, но в 7 фрагменте, отрицательное смещение и число кластеров несоответствующее. В таком случае, ошибка начинается после 69 EE. Подправил, создал 7 и 8-ой фрагмент ранлиста - всё сходится с last VCN и размерами в байтах.
Могу выложить на рецензию.

Цитата:

Не попутал названия? Или уточни что тогда раздел MFT.

MFT (Master File Table — Главная файловая таблица)
И я не писал что MFT это раздел

slepoy23
Но ты написал
Цитата:

был убит MFT вирусом файловая система NTFS) я удалил все разделы на харде а потом этой прогой востановил разделы

Повторяю, указанная программа не восстанавливает MFT, так что есть неувязочка в написанном тобою. Поэтому полностью согласен с ранее написанным Antech-ем.

Цитата:

atdevilru
Шлейф заменили?
Скажу честно: такой длинный ранлист я вкуривать сейчас не буду. Время не резиновое. Я не знаю как на работе можно столько времени уделять восстановлению на форумах. Заморачиваться с этим есть смысл только ради спортивного, а я уже несколько раз подобное делал, когда время было...

Шлейф естественно заменял, замена ни на что не повлияла.


Цитата:

Antech
Странно, но в 7 фрагменте, отрицательное смещение и число кластеров несоответствующее. В таком случае, ошибка начинается после 69 EE. Подправил, создал 7 и 8-ой фрагмент ранлиста - всё сходится с last VCN и размерами в байтах.
Могу выложить на рецензию.

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

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

atdevilru
Конечно же твой случай.
Шлейфы наиболее частые виновники ошибок, особено если их "прессовали" рукопопые свинтильщики.
Но бывают и более серьёзные причины - в том числе и проблемы с южником.

Цитата:

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

с помощью Р-студии я вытащил 60 гигов мусора нечитабельного, с непонятными расширениями и прочим. А этот же раздел после помощи Antech - стал как и прежде , и читабелен и со всем содержимым. поэтому и жду дальше вашей помощи.

с Самсунгом я понял так:
вариант1 - если данные важны - с помощью ДМДЕ посекторно скопировать диск и дальше пробовать из образа восстанавливать данные.

вариант 2 - если данные НЕважны -
пока в непонятках ... параметр 20 - это можно диск выкидывать?
или отформатировать? или что с ним сделать?

bai01
20-й аттрибут означает что данные об MFT хранятся не в стандартном ранлисте.
И восстановить так, как было в первом случае (где был всего один фрагмент) не так просто, и займёт наверняка огромное кол-во времени.
Для минимального представления сути и обьёма, возьми и просмотри отчёт сканирования NTFS для раздела G а затем повыписывай всё, что имеет схожие аттрибуты, как на приведённом скриншоте -
А на нём лишь малая часть. Так понятнее?

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

bai01
В общем-то 9285 уже все рассказал, если картко, то проблема вовсе не в 20-м атрибуте, а в том, что он появляется только при очень большом количестве фрагментов MFT, и врядли кто-то захочет тратить столько времени на формирование ранлиста.

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

Antech

Цитата:

не в 20-м атрибуте, а в том, что он появляется только при очень большом количестве фрагментов MFT

Насколько понял, если потом число фрагментов уменьшается то аттрибут всё равно остаётся? Если это так, то у bai01 есть хороший шанс.

9285

Цитата:

если потом число фрагментов уменьшается то аттрибут всё равно остаётся?

Вроде да.
Но Вы же говорили, что офигели от количества фрагментов в результатах поиска. Я сейчас тоже посмотрел, с тем же результатом. Это не раздел, это клиника. Мало того, что находится более 500 начал разделов, да еще и фрагментов MFT вообще не счесть. Даже если там нужны не все, кто будет обрабатывать этот хлам? Т.е. нужна прога для автоматического поиска цепочек фрагментов по результатам DMDE, которая бы не только прочитала/распарсила лог-файл и определила последовательность фрагментов, но и сама составила ранлист для патчевания, причем врядли там без 20-го обойдется... Например, я видел последовательность фрагментов, по-моему по 2048 записей, которые начинаются/заканчиваются "нос в хвост", т.е. формируют непрерывную последовательность записей. И таких там, наверное, не одна...

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

Прикол такой: перезагрузил Вин7 на буке и случился "великий П". Симптомы такие: Если пытаться загрузить на данном компе что-то вроде Win PE - вылетает в синий экран. Если подключить данный хард к другому компу, где уже запущена винда - винда вылетает синим экраном. Акронис Диск Директор видит нереальную картинку: 1 - локальный том (реальный диск С - объем соответствует действительности); 2 - локальный том (реальный диск Д - все соответствует); 3 - локальны том (основной MBR 281,1Гб - не отформатирован - такого никогда не было); 4 - Не занято 465,8Гб (полный реальный объем харда - данных никаких).
На 1 и 2 томах видит файлы - уже все восстановил. Проблема в том, что по отношению к томам 2, 3 и 4 не возможно применить какие либо действия (удаление и т.п.): коды такие 0х950014 (Сбой применения), 0х360194 (сбой проверки Fdisk), 0x10302F (не удается удалить том), 0х108408 (не удается найти том MBR на диске).
Вопрос: что сделать чтобы на диске пропало ВСЁ? Обнулить сигнатуру носителя в MBR? Обнулить 6 байт? Если ДА - то что значит "обнулить" - вписать туда 0?
Спасибо.

VasiliskA89
Я не знаю что имеется в виду под сигнатурой, но если речь о том, что в описании MBR из шапки (выделено салатновым), то это не поможет.
Если реально нет желания решить достаточно элементарную задачу и ничего не нужно, то можно обнулить (в порядке возрастания): его конец (55AA) + (или) таблицу разделов или весь сектор. Но это сделает диск как бы без ничего, хотя на самом деле останется весь мусор.

9285
Что вы подразумеваете под "обнулить"? Меня это вполне устроит. Пусть он будет таким как будто его только что принесли из магазина)

VasiliskA89
Чтобы он был как будто из магазина, его надо обнулить весь.
Обнуление - запись нулей в нужные сектора.

9285
Подскажите что и куда нужно записать (нужно что-то от меня?)
Спасибо

VasiliskA89, походу в таблице разделов две (или одна) лишние строки и всё. Это хорошо, что Акронис грузится. Там есть Acronis Hex Editor, им можно открыть диск и либо обнулить эти строки, либо весь 0-й сектор.

Sphinx114
Строчки искать не вариант. Подскажите в каких адресах записать "0". И каков вообще порядок действий.

VasiliskA89, в акронисе "Диск N" - ПКМ - дополнительно - правка - F2 - выделяешь 0-й сектор - правка - заполнить - OK - правка - сохранить сектор.

0 сектор - с какого по какой адресс (пока нет таких глубоких познаний).

VasiliskA89, от 0 до 1FF

Sphinx114
Спасибо, помогло - буду учиться дальше

VasiliskA89
Учиться чему? Уничтожению?
Вот если бы восстановил то что было, и сохранил данные оттуда а не не вытаскивал хлам рековерилками, тогда было бы понятно.

Спасибо огромное. очень выручили. познаем непознаваемое)

9285

Цитата:

программе может и сложно расспарсить все эти комбинации

Алгоритм такой:
1. Упорядочиваем все фрагменты по номеру начальной записи.
2. Задаем номер текущего фрагмента = 0, пишем его номер в массив последовательности, помечаем его как использованный.
3. Просматриваем список фрагментов, начиная с текущего+1, в поисках такого фрагмента, у которого номер начальной записи равен номеру последней записи текущего фрагмента + 1. Если таковой находится, то меняем номер текущего фрагмента на номер найденного фрагмента, пишем его в массив последовательности, помечаем его как использованный и переходим опять к п. 3. Если такой не находится, то закрываем данную последовательность.
4. Задаем номер текущего фрагмента равным первому из неиспользуемых, выполняем п. 2 (кроме задания текущего фрагмента) и переходим к п. 3. Если ниспользованных фрагментов не осталось, заканчиваем обработку.
Вот такой нехитрый алгоритм, описание несколько кривое, но смысл очевиден. Он применим только для MFT, в которой есть номера записей. Учитывает реликты: если между двумя "настоящими" фрагментами вклинился один или несколько реликтовых фрагментов, алгоритм пропустит их и в список добавлять не будет. Также он поддерживает несколько последовательностей фрагментов, например, если проискана область более чем одного раздела. Использовать его можно по существующим результатам поиска в DMDE.
Т.е. теоретически фича реализуема. Практически будет вполне работоспособно на не слишком twisted результатах поиска. Но это надо в DMDE встраивать, моя прога не имеет функции формирования фрагментов MFT, да и времени нет пока что...

VasiliskA89
Лучше идеи не нашлось... Неужели так трудно было почистить PT? В шапке есть ссылка на прекрасный мануал по MBR-Style разметке...
А то, что Вы сделали, тут никаких байт вообще не нужно: взяли бы HDDScan - Tests - Surface - Write. Но к теме это уже совершенно не относится, т.к. стирает все содержимое диска.

Здравствуйте Antech и 9285, не поможете мне разобраться со структурой boot сектора на планшетном компьютере ради спортивного интереса?
В наличии имеется дамп диска под виртуальную машину VMware, который частично соответствует дампу прошивки реального устройства.
Отсюда следует, что если разобраться в организации разделов под виртуальной машиной, то и на устройстве всё будет справедливо.
Из анализа диска, проведённого мной, выяснено, что MBR находится в 640 секторе (видимо в начале находятся цифровые подписи прошивки?)
Структура MBR имеет вполне стандартный вид, с ней вроде бы всё понятно, кроме нестандартной файловой системы, System ID = 0xB3, т.е QNX Neutrino Power-Safe filesystem.
Из MBR берём относительное смещение (0x01C6), оно равно 3F, умножаем на размер сектора, т.е 512 байт, получаем адрес 7E00, перейдя от начала MBR на смещение 7E00 приходим к boot сектору, вот тут то и начинаются проблемы, после первых 3х байт (Jump instruction), не идёт OEM ID, как указано в большинстве статей, а идёт не понятно что, вот тут мне и нужна помощь специалистов, как расшифровать организацию данных записей? Есть ли какая-нибудь литература про устройство файловых систем unix (структуру QNX Neutrino Power-Safe filesystem я думаю найти нереально), а то я обыскался, нигде ничего нету.
Если предположить, что OEM ID просто пропускаем, то следующий, по идее, должен идти размер сектора, а он варьируется от версии прошивки, получается ерунда.
Причём при загрузке MBR позволяет выбрать с какого раздела (бут сектора) грузиться, поэтому в дампе имеется ещё один бут сектор, сравнивая их получаем следующую картинку:

т.е отличаются только 6 байтов в первой строке, отсюда я предположил что в данной строке каким-то образом закодирован адрес на который передаётся управление кодом самого бутлаодера, на этом я и заступорился, как из 2х адресов собрать один верный?
Также прикрепляю дампы секторов MBR+100 и boot+100.
http://zalil.ru/31679258

Ещё имеется штук 8 прошивок для устройства, ответа на вопрос из их анализа я, конечно же, не получил.
Заранее спасибо за помощь в любом её проявлении.

atdevilru
Я в данном вопросе не помощник, хотя кое что всё таки отвечу.
1. Посмотри Б. Кэрриэ - Криминалистический анализ файловых систем
2. У меня на втором винте установлена убунта. Её раздел начинается в 63-ем секторе, и там (вместо привычных символов) одни нули.
Насколько понимаю, все эти идентификаторы относительны. Главное что бы загрузчик сам понял что считывать и делать. Сейчас стали распространены различные видеорегистраторы. Вот в них разработчики соревнуются в умении "Кто во что горазд".

PS. Если понадобится патч для твоего случая - маякни.

9285

Цитата:

Её раздел начинается в 63-ем секторе, и там (вместо привычных символов) одни нули

Правильно, и еще один сектор будут нули (это резерв для загрузчика), а потом только суперблок. Вау, я даже помню как это называется... Когда-то лазил по ext2/3, но уже забыл давно ее структуру... Там нет никаких magic-строк в суперблоке, есть только magic number, и суперблок занимает 2 сектора вместо одного под BS в ФС от M$.
Но у atdevilru явно не ext2/3, так что тут вообще вопрос какая это ФС. Начало больше в традициях M$, чем в линуксовых (нет двух секторов для загрузчика, бут начинается с JMP).

Antech
Вы же понимаете что в моём ответе процитированная фраза имеет продолжение.
И смысл в том, что каждая ФС строится по своим правилам, и они могут отличаться коренным образом. Поэтому не надо удивляться отсутствию тех или иных элементов.