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

The_Immortal
Теперь нужны дампы следующих записей MFT 78725, 165532, 78217, 14593, 15466, 22140
Открываешь том, потом переходишь к соответствующей записи (Alt+F) и делаешь дамп сектора куда перейдёшь+следующего.

temp9285, уточните, пожалуйста, дампы снимать с бэкап-варианта или с чекдискнутого варианта? Или с обоих?

дампы снимают чтоб откатить изменения, там смотреть нечего, смотреть надо в гуй

The_Immortal
Конечно с бэкапа.

bomzzz
Лучше бы промолчал. Или посмотрел "в гуй".

bomzzz, что есть гуй и как в него смотреть?

temp9285, сделал с обоих, т.к. в чекдискнутом варианте секторы для тех же MFT другие (но не у всех) - может быть это важно, не знаю. И кстати, чекдискнутый вариант - там уже пройден чекдиск как в режиме чтения, так и с ключами /f /r. Могу сделать вариант образа раздела после чекдиска только в режиме чтения, если есть необходимость. Ибо уже после чтения чекдиск убил 4 гига, хотя должен по идее лишь "читать".

Мне ещё посоветовали вот что:
Цитата:

Единственно что — можно найти первый фрагмент по заголовку: первые 4 байта (!BDN в текстовом представлении) и байты с 8 по 15 (начинаются с SM в текстовом представлении) в них одинаковы.

- только, к сожалению, не знаю как искать по заголовку через DMDE. Вроде гуглил, но ответа не обнаружил.

гуи - это окно программы

Добавлено:
/f - параметр, который задает исправление ошибок на диске.
это параметр /r, который обнаруживает поврежденные сектора диска и восстанавливает ту часть данных, которая еще может быть прочитана.
http://www.windowsfaq.ru/content/view/247/57/

Добавлено:
файлы R studio восстаналивают вроде в основном. зависит от того что надо восстановить. пользоваться не доводилось, пару раз текстовые файлы удалял и восстаналивал совсем простенькой прогой

The_Immortal
Дамп после чекдиска спрашивал ранее чтобы посмотреть что изменилось в нужной записи.
Сейчас это не нужно. Если и понадобиться после чекдиска - уточню.
Что касается сигнатур и остального - отвечу, но не сейчас.
Сейчас только кратко - запускай в DMDE 3.х поиск NTFS и ищи в результатах RAW-поиска. Это если она знакома с данным форматом.
В любом случае - сохрани лог и выложи.

Добавлено:
В дампах не то. Или вообще не запись MFT или другая, причём со смещение.
Ты смотри в правом нижнем окне (если что - включи режим Файл MFT) там видно номер записи MFT.
Типа MFT N0 xxxxxx
Находясь в нужной делай дамп сектора, а число секторов 2. Имя файла не меняй, я сам увижу номер записи.

south_man
Вернул диск на родину.

Итог:
1. Дисковые пространства:


2. Управление дисками: Диск 2 - это он и есть, CD-ROM 0 это виртуальный диск, который автоматически монтировался при присоединении диска и сод- ержал какую-то служебную программу, драйвера какие-то вроде.


3. И вот такие ошибки в DMDE при выборе диска:

или такая:


Может при выборе какие особые параметры выбрать, чтобы была возможность открыть?
С прошлым карманом оно хоть размер всего диска видело и в ДМДЕ открывало для сканирования.


temp9285
Подскажите, а не могли бы вы глянуть моё сообщение выше тоже?

cash2000
Ссылка

temp9285, Бога ради, извините - я прошлый раз глюканул и в значение сектора переписывал логический сектор взятый из MFT, а не LBA. Оказывается, что переписывать ничего не надо: там уже сидит нужный сектор соответствующий обнаруженной MFT. Теперь переделал (лог полного сканирования тоже прилагаю).

Правда, в этих секторах ничего полезного лично я не увидел - там пустые MFT (кроме первого)...
А в логе полного сканирования я не обнаружил ни !BDN, ни SM - это как-то странно, ибо pst файлы-то другие там должны быть...
Но вполне вероятно, что я не туда смотрю.

BOBAH4IK
Статью почитал.
Вы имеете в виду, что он не может расшифровать информацию что ли?
Я же жесткий диск вернул обратно в родной карман.

cash2000
Есть 100% уверенность, что карман исправен?

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

Т.е., если он не исправен, вся информация на жестком зашифрована и достать ее возможно только при манипуляциях, о которых шла речь в 36-ти страничном докладе из статьи по вашей ссылке? )

cash2000

Цитата:

Т.е., если он не исправен, вся информация на жестком зашифрована и достать ее возможно только при манипуляциях, о которых шла речь в 36-ти страничном докладе из статьи по вашей ссылке? )

Если есть не преодолимое желание постичь кухню, то пожалуйста. Есть и другие варианты.
1. Приобрести необходимое оборудование для работы с такими драйвами.
2. Обратиться с специалистам, имеющим такое оборудование.

cash2000
Если бы я мог что то написать по твоему случаю, то сделал бы это.
south_man с самого начала написал о причине ненахождения данных.
Мне (на тот момент) нечего было добавить. Что касается текущего состояния, то я не знаю что и ответить - я физически не сталкивался с такими винтами. Единственное что могу - спросить "Ты точно не инициализировал диск когда он был подключен без бокса?".

The_Immortal

Цитата:

Правда, в этих секторах ничего полезного лично я не увидел - там пустые MFT (кроме первого)...

На самом деле там много интересного, хотя есть и непонятность.
Я лишь поверхностно знаком с расширенным аттрибутом, и не очень понимаю его структуру. Тем более что имеющиеся в моём распоряжении дампы нескольких случаев показывают что она бывает нескольких видов.
В записях, которые предоставил ты, записи MFT (причём мизерная часть) в которых перечислены кластера с расположением нужного тебе файла. Но, по неизвестной мне причине, они "не рабочие" - не знаю как тебе по другому обьяснить. То есть запись как бы обрезана несколькими строчками, хотя дальше чётко отслеживаются ранлисты. Возможно что число фрагментов стало каким то критическим (а их было не одна тысяча ) и система начала формировать новый список но не успела сделать.
Даже если вычленить все ранлисты, то это требует немеряного времени; но самое главное что это может быть бессмысленным в случае если какой то из участков будет некорректным (или уже что то перезаписалось)

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


Цитата:

А в логе полного сканирования я не обнаружил ни !BDN, ни SM - это как-то странно, ибо pst файлы-то другие там должны быть...

!BDN - это сигнатура начала файла, которую можно увидеть в секторах (*).
Ну а что касается результата поиска, то видимо DMDE (пока?) не знает сигнатуры pst-фалов. Хотя наверняка другое ПО знакомо.
(*) Кстати, там же можно узнать и размер файла - это не критично для фрагментированного файла, но может хотя бы понять заголовок какого файла найден. В принципе. размер файйла можно узнать и из индекса папки, которые находятся в секторе 99930912+7 последующих.

temp9285,
Цитата:

В принципе. размер файйла можно узнать и из индекса папки, которые находятся в секторе 99930912+7 последующих.

А как это узнать? Я в 99930912 вижу внизу сектора только "O.u.t.l.o.o.k...p.s.t"
Цитата:

Ну а что касается результата поиска, то видимо DMDE (пока?) не знает сигнатуры pst-фалов

Дык надо же тупо считать все файлы в 16-ричном представлении - неужели ему это так сложно сделать?
Цитата:

Хотя наверняка другое ПО знакомо.

А как найти такое ПО? Что-то не могу сообразить с запросом... Нахожу только что-то типа такого.
Цитата:

хотя дальше чётко отслеживаются ранлисты.

А как Вы это видите?) Хочу посмотреть Вашими глазами... Может въеду и буду дальше расследовать...

[more]







[/more]
как правильно удалить эти следы непонятно от чего, потому что кроме дмде это никто не находит. винт разбивался один раз, ничего не переделывалось и откуда когда и как они появились не знаю

temp9285
The_Immortal
Все нормально с записью о файле Outlook
Run лист не резидентный.
Лежит (или лежал) в кластере
12491364
https://yadi.sk/i/jog_JTwlmSdmc


bomzzz
Не парьтесь, так всегда на системном диске.
Система хранит кучу копий файловой структуры в различных временных файлах и виртуальных страницах памяти.

tomset, а если перевести на русский-приземленый - это хорошо или плохо? Лично я ничего не понял

The_Immortal

Цитата:

А как это узнать?

Перевести хексзначения в определённых байтах в привычные цифры.

Цитата:

А как найти такое ПО?

Смотреть в описании программы какие типы файлов восстанавливаются сигнатурно. Если такого нет, то просто проверять в действии.
Скорей всего с такими знакомы R-studio, Photorec (при работе с ним надо учитывать специфику его работы). На приведённой тобой странице виден скрипт (или скрипт для неё) Active@ File Recovery.
Можно использовать программы, позволяющие добавлять свои сигнатуры.
Только пойми одно - они актуальны для нефрагментированного файла, или хотя бы для случая, если из этого первого фрагмента можно что то извлечь (программами по восстановлению данных из таковых).

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

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

PS. Судя по вашим описаниям PC3000 ну просто чудеса творит.
Вот сможет ли она восстановить "кусок мяса из такого вот фарша"?

temp9285, охрендеть! Я запустил этот Active File Recovery, впихнул тот скрипт и запустил поиск. Прошло 5 минут и он обнаружил один pst файл размером 1,04 GB! Называется Found_какие-то_цифры. Помечен удаленным.
Сейчас дождусь окончания сканирования...

tomset
не всегда. это можно стереть. хотелось бы разобраться как сделать это правильно.

temp9285, короче. Восстановил он файл Found_635645448_1115374592.pst весом 1.03 GB. Я попытался его подпихнуть в Outlook - тот ругнулся на ошибки. Я его запихнул в SCANPST - там на 3 этапе все тормознулось "из-за ошибок" (( Есть лог обработки файла, но не знаю, что это даст...

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

The_Immortal
Давай дождёмся результата, хотя подозреваю что речь идёт о случае, когда находится заголовок файла, из него считывается размер, и потом "находится" файл от первого сектора и на длину размера". В случае нефрагментированого файла это сработает, но у тебя другой случай (*).
Впрочем, а вдруг как раз перед сбоем система собрала файл воединно, но не успела изменить запись в MFT? Хотя это из разряда фантастики.

(*) В ходе некоторых своих экспериментов и т.п., сталкивался с ситуацией когда файл имел расширенный атрибут и множество частей. Я дефрагментировал раздел. Файл реально собрался в один кусок, но при этом расширенный атрибут остался и в нём фигурировало что файл многофрагментный. Видимо в NTFS нет штатного возврата к обычному ранлисту. Так что, ещё один гипотетический шанс имеется, но даже он действителен лишь в случае если кластера дефрагментировались последовательно.

Добавлено:

Цитата:

Восстановил он файл Found_635645448_1115374592

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

temp9285, помучил этот файл через другую программу - она делает превью писем. В общем, похоже там сидят письма из Outlook.bak (до 2013 года). Размер явно фейковый... Но интересно то, что там засветилось одно единственное письмо 6 писем от 2015 года! Как оно туда попало...
Цитата:

Подозреваю что в секторе 635645448 находится заголовок файла,

Точно так: 635645448 - там в начале сидит тот самый !BDN...SM
Цитата:

а второй число и есть размер в байтах

И это так.
Цитата:

дамп этого начального сектора и кластер, о котором писал чуть выше - 99930912+7 последующих

Держите.

The_Immortal
Я думаю что размер не фэйковый а реальный. И начало файла реальное. Тем более что начальный фрагмент достаточно большой и видимо сформировался на ещё не очень занятом разделе. Далее пошла фрагментация файл - что вполне естественно для расширяющего по времени файла.
Что же касается письма от 2015 года, то и этому есть обьяснение - программ по восстановлению баз ищут в месиве характерные записи и выводят что соотвествует им. Вот представь газеу, которую разорвали на кучу клочков, причём разного размера. Ведь не исключено что в каком то попадётся часть статьи, а каком то полностью кусок какого то небольшого обьявления. То есть как бы есть и неполные фрагменты, и даже полные, но всей газеты нет.

temp9285, в любом случае есть подозрение, что это не искомый файл:
Цитата:

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

The_Immortal
Дамп кластера делался из оригинала тома?
Просто номер сектора рассчитан от начала тома, а (подозреваю) что ты работаешь не с образом а с винтом, на который откатан образ. Тем более что номер сектора начала pst явно за пределами числа секторов в проблемном разделе.
Кстати, исходя из описания структуры заголовка, там фигурирует размер базы около 7 мегабайт.

temp9285, эм... Я вчера присылал дампы с раздела, на который накатан образ, т.е. условно оригинальный раздел. И сейчас я также сделал оттуда же и эти дампы...
Если я таким образом запутываю, то могу передать - только подскажите как именно
Цитата:

размер базы около 7 мегабайт.

Эм... 7 МБ pst?
Тьфу пардон! Дамп сектора и дамп кластера - у меня в единое слилось (время уже позднее, подзасыпаю). Я Вам там выше делал дампы секторов только.
Погодите... Я в конец запутался. Физический сектор - это "LBA" (по DMDE). Кластер - это "Клас." (по DMDE). А ещё есть "лог. сек." (логический сектор). Так вот 12491364 - это кластер, который соответствует лог. секторам 99930912+7. В общем, вот он

The_Immortal

Цитата:

Я вчера присылал дампы с раздела, на который накатан образ, т.е. условно оригинальный раздел.

Насколько я понимаю, раздел не с начала диска и если ты открываешь раздел через таблицу разделов (это когда открываешь физический диск), то номер сектора применяется к физическому диску. Другое дело если ты его открываешь как логический диск.
Что касается кластера-сектора, то сектора 99930912+7 это и есть один кластер.

Что сасается размера 7 мб, то в заголовке базы, в указанном в статье месте, фигурирует B1 D5 6F 00
Для расчёта в обычном числе надо брать это значение в обратном порядке 00 6F D5 B1 и он равно 7329201 (байт).

Добавлено:
Вот, это нужный дамп. И судя по индексам (насколько я понимаю), вырисовывается размер 1350743937.
Что как бы соответствует на твоим сведениям.