Ru-Board.club
← Вернуться в раздел «Магнитные носители информации»

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

Автор: temp9285
Дата сообщения: 22.12.2015 19:36
The_Immortal
Теперь нужны дампы следующих записей MFT 78725, 165532, 78217, 14593, 15466, 22140
Открываешь том, потом переходишь к соответствующей записи (Alt+F) и делаешь дамп сектора куда перейдёшь+следующего.
Автор: The_Immortal
Дата сообщения: 22.12.2015 20:16
temp9285, уточните, пожалуйста, дампы снимать с бэкап-варианта или с чекдискнутого варианта? Или с обоих?
Автор: bomzzz
Дата сообщения: 22.12.2015 20:35
дампы снимают чтоб откатить изменения, там смотреть нечего, смотреть надо в гуй
Автор: temp9285
Дата сообщения: 22.12.2015 20:52
The_Immortal
Конечно с бэкапа.

bomzzz
Лучше бы промолчал. Или посмотрел "в гуй".
Автор: The_Immortal
Дата сообщения: 22.12.2015 20:54
bomzzz, что есть гуй и как в него смотреть?

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

Мне ещё посоветовали вот что:
Цитата:
Единственно что — можно найти первый фрагмент по заголовку: первые 4 байта (!BDN в текстовом представлении) и байты с 8 по 15 (начинаются с SM в текстовом представлении) в них одинаковы.
- только, к сожалению, не знаю как искать по заголовку через DMDE. Вроде гуглил, но ответа не обнаружил.
Автор: bomzzz
Дата сообщения: 22.12.2015 20:59
гуи - это окно программы

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

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

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

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


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


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

или такая:


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


temp9285
Подскажите, а не могли бы вы глянуть моё сообщение выше тоже?
Автор: BOBAH4IK
Дата сообщения: 22.12.2015 22:10
cash2000
Ссылка
Автор: The_Immortal
Дата сообщения: 22.12.2015 22:59
temp9285, Бога ради, извините - я прошлый раз глюканул и в значение сектора переписывал логический сектор взятый из MFT, а не LBA. Оказывается, что переписывать ничего не надо: там уже сидит нужный сектор соответствующий обнаруженной MFT. Теперь переделал (лог полного сканирования тоже прилагаю).

Правда, в этих секторах ничего полезного лично я не увидел - там пустые MFT (кроме первого)...
А в логе полного сканирования я не обнаружил ни !BDN, ни SM - это как-то странно, ибо pst файлы-то другие там должны быть...
Но вполне вероятно, что я не туда смотрю.
Автор: cash2000
Дата сообщения: 22.12.2015 23:34
BOBAH4IK
Статью почитал.
Вы имеете в виду, что он не может расшифровать информацию что ли?
Я же жесткий диск вернул обратно в родной карман.
Автор: BOBAH4IK
Дата сообщения: 23.12.2015 05:53
cash2000
Есть 100% уверенность, что карман исправен?
Автор: cash2000
Дата сообщения: 23.12.2015 14:01
BOBAH4IK
Никаких манипуляций с ним до момента, как перестал диск определяться, не осуществлялось, не падал, перемещался разве что со стола на стол.
От перепада напряжения мог бы выйти из строя? Хотя был подключен всегда через сетевой фильтр...

Т.е., если он не исправен, вся информация на жестком зашифрована и достать ее возможно только при манипуляциях, о которых шла речь в 36-ти страничном докладе из статьи по вашей ссылке? )
Автор: BOBAH4IK
Дата сообщения: 23.12.2015 15:04
cash2000

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

Если есть не преодолимое желание постичь кухню, то пожалуйста. Есть и другие варианты.
1. Приобрести необходимое оборудование для работы с такими драйвами.
2. Обратиться с специалистам, имеющим такое оборудование.
Автор: temp9285
Дата сообщения: 24.12.2015 00:24
cash2000
Если бы я мог что то написать по твоему случаю, то сделал бы это.
south_man с самого начала написал о причине ненахождения данных.
Мне (на тот момент) нечего было добавить. Что касается текущего состояния, то я не знаю что и ответить - я физически не сталкивался с такими винтами. Единственное что могу - спросить "Ты точно не инициализировал диск когда он был подключен без бокса?".

The_Immortal

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

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

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


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


!BDN - это сигнатура начала файла, которую можно увидеть в секторах (*).
Ну а что касается результата поиска, то видимо DMDE (пока?) не знает сигнатуры pst-фалов. Хотя наверняка другое ПО знакомо.
(*) Кстати, там же можно узнать и размер файла - это не критично для фрагментированного файла, но может хотя бы понять заголовок какого файла найден. В принципе. размер файйла можно узнать и из индекса папки, которые находятся в секторе 99930912+7 последующих.
Автор: The_Immortal
Дата сообщения: 24.12.2015 00:42
temp9285,
Цитата:
В принципе. размер файйла можно узнать и из индекса папки, которые находятся в секторе 99930912+7 последующих.
А как это узнать? Я в 99930912 вижу внизу сектора только "O.u.t.l.o.o.k...p.s.t"
Цитата:
Ну а что касается результата поиска, то видимо DMDE (пока?) не знает сигнатуры pst-фалов
Дык надо же тупо считать все файлы в 16-ричном представлении - неужели ему это так сложно сделать?
Цитата:
Хотя наверняка другое ПО знакомо.
А как найти такое ПО? Что-то не могу сообразить с запросом... Нахожу только что-то типа такого.
Цитата:
хотя дальше чётко отслеживаются ранлисты.
А как Вы это видите?) Хочу посмотреть Вашими глазами... Может въеду и буду дальше расследовать...
Автор: bomzzz
Дата сообщения: 24.12.2015 00:52
[more]







[/more]
как правильно удалить эти следы непонятно от чего, потому что кроме дмде это никто не находит. винт разбивался один раз, ничего не переделывалось и откуда когда и как они появились не знаю
Автор: tomset
Дата сообщения: 24.12.2015 01:16
temp9285
The_Immortal
Все нормально с записью о файле Outlook
Run лист не резидентный.
Лежит (или лежал) в кластере
12491364
https://yadi.sk/i/jog_JTwlmSdmc


bomzzz
Не парьтесь, так всегда на системном диске.
Система хранит кучу копий файловой структуры в различных временных файлах и виртуальных страницах памяти.
Автор: The_Immortal
Дата сообщения: 24.12.2015 01:27
tomset, а если перевести на русский-приземленый - это хорошо или плохо? Лично я ничего не понял
Автор: temp9285
Дата сообщения: 24.12.2015 01:33
The_Immortal

Цитата:
А как это узнать?

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

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

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

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

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

PS. Судя по вашим описаниям PC3000 ну просто чудеса творит.
Вот сможет ли она восстановить "кусок мяса из такого вот фарша"?
Автор: The_Immortal
Дата сообщения: 24.12.2015 01:54
temp9285, охрендеть! Я запустил этот Active File Recovery, впихнул тот скрипт и запустил поиск. Прошло 5 минут и он обнаружил один pst файл размером 1,04 GB! Называется Found_какие-то_цифры. Помечен удаленным.
Сейчас дождусь окончания сканирования...
Автор: bomzzz
Дата сообщения: 24.12.2015 01:58
tomset
не всегда. это можно стереть. хотелось бы разобраться как сделать это правильно.
Автор: The_Immortal
Дата сообщения: 24.12.2015 02:08
temp9285, короче. Восстановил он файл Found_635645448_1115374592.pst весом 1.03 GB. Я попытался его подпихнуть в Outlook - тот ругнулся на ошибки. Я его запихнул в SCANPST - там на 3 этапе все тормознулось "из-за ошибок" (( Есть лог обработки файла, но не знаю, что это даст...

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

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

Добавлено:

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

Подозреваю что в секторе 635645448 находится заголовок файла, а второй число и есть размер в байтах.
Ну а причину неоткрытия я написал чуть выше.
Кстати, сбрось дамп этого начального сектора и кластер, о котором писал чуть выше - 99930912+7 последующих.
Автор: The_Immortal
Дата сообщения: 24.12.2015 02:20
temp9285, помучил этот файл через другую программу - она делает превью писем. В общем, похоже там сидят письма из Outlook.bak (до 2013 года). Размер явно фейковый... Но интересно то, что там засветилось одно единственное письмо 6 писем от 2015 года! Как оно туда попало...
Цитата:
Подозреваю что в секторе 635645448 находится заголовок файла,
Точно так: 635645448 - там в начале сидит тот самый !BDN...SM
Цитата:
а второй число и есть размер в байтах
И это так.
Цитата:
дамп этого начального сектора и кластер, о котором писал чуть выше - 99930912+7 последующих
Держите.
Автор: temp9285
Дата сообщения: 24.12.2015 02:28
The_Immortal
Я думаю что размер не фэйковый а реальный. И начало файла реальное. Тем более что начальный фрагмент достаточно большой и видимо сформировался на ещё не очень занятом разделе. Далее пошла фрагментация файл - что вполне естественно для расширяющего по времени файла.
Что же касается письма от 2015 года, то и этому есть обьяснение - программ по восстановлению баз ищут в месиве характерные записи и выводят что соотвествует им. Вот представь газеу, которую разорвали на кучу клочков, причём разного размера. Ведь не исключено что в каком то попадётся часть статьи, а каком то полностью кусок какого то небольшого обьявления. То есть как бы есть и неполные фрагменты, и даже полные, но всей газеты нет.
Автор: The_Immortal
Дата сообщения: 24.12.2015 02:40
temp9285, в любом случае есть подозрение, что это не искомый файл:
Цитата:
есть подозрение, что это некогда резервная копия того самого pst, которую я зачем делал, а потом за ненадобностью удалил...
Автор: temp9285
Дата сообщения: 24.12.2015 02:41
The_Immortal
Дамп кластера делался из оригинала тома?
Просто номер сектора рассчитан от начала тома, а (подозреваю) что ты работаешь не с образом а с винтом, на который откатан образ. Тем более что номер сектора начала pst явно за пределами числа секторов в проблемном разделе.
Кстати, исходя из описания структуры заголовка, там фигурирует размер базы около 7 мегабайт.
Автор: The_Immortal
Дата сообщения: 24.12.2015 02:46
temp9285, эм... Я вчера присылал дампы с раздела, на который накатан образ, т.е. условно оригинальный раздел. И сейчас я также сделал оттуда же и эти дампы...
Если я таким образом запутываю, то могу передать - только подскажите как именно
Цитата:
размер базы около 7 мегабайт.
Эм... 7 МБ pst?
Тьфу пардон! Дамп сектора и дамп кластера - у меня в единое слилось (время уже позднее, подзасыпаю). Я Вам там выше делал дампы секторов только.
Погодите... Я в конец запутался. Физический сектор - это "LBA" (по DMDE). Кластер - это "Клас." (по DMDE). А ещё есть "лог. сек." (логический сектор). Так вот 12491364 - это кластер, который соответствует лог. секторам 99930912+7. В общем, вот он
Автор: temp9285
Дата сообщения: 24.12.2015 02:58
The_Immortal

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

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

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

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

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354

Предыдущая тема: Проблема HDD с востновлениям информациии


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.