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

makcunknown
Да уж. Есть уверенность что посекторка сделана правильно?
Ну никак не могу сфантазировать как по другому можно обьяснить такой глобальный сдвиг.
Как вариант, анализировать что восстанавливается корректно по файловой системе - смотреть номера секторов и что в файловой записи. Исходя из этого определить смещение.

Добавлено:
The_Immortal

Цитата:

а в некоторых каталогах оказывалась совсем другая информация.

Возможны логические ошибки файловой системы - простые лечатся чекдиском.

Цитата:

Отыскал нужные файлы (doc, docx) в том каталоге, который не открывался. Восстанавливаю эти файлы, но они не открываются

Причин множество - например, какой то мусор в секторах, в том числе и в записях файловой системы. Последнее приводит к тому, что данные вычитываются не с тех кластеров, где они расположены.
Можно попробовать сигнатурный поиск. В идеале было бы хорошо если бы нашёлся целым один из таких неоткрываемых. Тогда можно проанализировать соответствие расположение файла записи в MFT.

Добавлено:
Забыл уточнить - предполагается что данные файлы обычного формата, т.е. не защифрованы пользователем или вирусом и т.п.

temp9285
Есть уверенность что посекторка сделана правильно?

Да, даже с винта при сканировании на первом гиге выдаёт этот надежный раздел (который сдвинут на 31Гиг, далее просто ищет файлы, которые восстанавливаются с ошибкой, я так понимаю никак это уже не исправить, спец один сказал есть возможность только через вручную восстанавливать транслятор.

makcunknown
Я не знаю что подразумевается под транслятором. А то в ролике аси есть про восстановление транслятора, который не более чем бутсектор раздела. Если про такой, то не вижу перспективы.
Если речь о служебке, то возможно что поможет, но это у других надо узнавать.

temp9285, если после полного сканирования открыть том, то там будет раздел RAW-файлов. По каждому типу файлов можно увидеть список, элементы которого маркируются по-разному: иконка зеленая, иконка с красным и т.д. Я так понимаю, что наличие красного обозначает поврежденный файл. Но при этом имена файлов неизвестным. Вы не знаете каким образом можно узнать имя того или иного файла из этого списка? Или ещё лучше сразу получить список поврежденных файлов.

P.S. В справке помощи по данному вопросу не обнаружил.

The_Immortal
А что ты искал?
В справке по панели файлов есть описание двух типов "с красненьким".
Я не могу гарантировать что правильно понимаю, но попробую описать как думаю.
1. файл, найденный по сигнатурам, сигнатура конца не найдена - некоторые типы файлов имеют начальную и конечную сигнатуру - например jpeg. Соответственно, найдя начальную сигнатуру, можно искать конечную и всё между ними воспринимать как файл. Но если по пути встречается сигнатура другого файла (или ещё что то известное - те же метаданные ФС), то вполне логично предположить что на этом прежний файл обрывается. Вот в такой ситуации и можно обозначить файл таким обозначением.
2. файл по сигнатурам, определен размер, вероятна частичная перезапись
Всё почти как и в первом случае, только у файла нет сигнатуры конца, но зато в заголовке файла есть значение размера. Примеры таких файлов - bmp, cd (файл данных 1С 8.х).


Цитата:

Но при этом имена файлов неизвестны

Ну так при RAW поиске не учитываются данные ФС - откуда же знать имя?
Можно совместить результаты поиска, но только всё настолько неоднозначно, что толку - от 0% .

temp9285, благодарю. Но как мне получить список тех файлов? У этих же файлов есть нормальные имена, а не F123554.doc... Я понимаю, что имена файлов сидят в ФС, но как сопоставить эти файлы с файлами ФС?

The_Immortal

Цитата:

У этих же файлов есть нормальные имена, а не F123554.doc...

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

temp9285, я могу щелкнуть по файлу и в Редакторе ниже увидеть и сектор и кластер, только это ничего не дает...

The_Immortal
Мне пока тоже ничего не даёт твоё словесное описание.
Вот прикинь - ты открываешь doc-овскй файл а в заголовке не та сигнатура. Это может быть и последствием шифратора, и внедрение какого то мусора и неправильные данные о его размещении.
А если та, то причина может быть в том же мусоре, или шифраторе, который шифрует не весь файл а часть в начале (были и такие). Так что много что можно писать, но только всё это в пустоту.
Конкретизируй свои хотелки, выложи (в архиве) скриншоты на которых видно что в заголовке, сделай дамп секторов 40 заголовка и самой записи MFT (?).

Добавлено:
The_Immortal
Давай рассмотрим один алгоритм.
У тебя есть какой то файл найденный в RAW-поиске, имя которого тебе известно, но в обычном режиме он не восстанавливается.
Смотришь какие сектора (кластера) он занимает и какие в записи. Находишь ошибку.
Делаешь такое с ещё каким то другим файлом. Смотришь есть ли какие о аналогии - например вкрапление одинакового байта или одинаковое смещение данных. Если есть такое, то применяешь корректировки к другим проблемным данным.

temp9285, да все банально. Я уже смирился с тем, что нельзя восстановить тот или иной док-файл (точнее можно, но в итоге он получается нечитаемым). Мне бы просто хотелось получить список косячных файлов, чтобы понять стреляться али нет. Я подумал, что это можно сделать через RAW-анализ, отсортировав там файлы таким образом. Но, как я понял, узнать имя таких файлов невозможно, так?

Цитата:

У тебя есть какой то файл найденный в RAW-поиске, имя которого тебе известно

Так RAW и имя файла - вещи несовместимые же

The_Immortal
Как бы мне обьяснить тебе чтобы ты понял?
Можно проанализировать вручную если у тебя 100 файлов. но когда их тысяча это уже сложно.
Можно использовать метод. который упоминался раньше - карта занятого пространства. Но ведь она не возникнет сама по себе. Например, она будет базироваться на битовой карте тома (рассматриваю том NTFS) - но достаточно вклинивания одного не того бита чтобы нарушить её правильность. То есть можно предполагать 100500 вариантов, но как убедиться в этом? Особенно если для восстанавливающего название (содержимое файла) - ни о чём.

Цитата:

Так RAW и имя файла - вещи несовместимые же

Да. Но речь то о другом.
Предположим у тебя:
1 - в списке файлов есть фото с именем "Мы с Трезором на границе.jpg" и этот файл не восстанавливается в нормальном виде
2 - в результатах RAW поиска имеется фото на котором сфоткан человек с собакой на границе. Все остальные фотки с "котиками" И этот файл нормально открывается.
Вполне логично что это тот самый файл
Смотришь содержимое записи этого файла и видишь что файл начинается с кластере ХХХ, а в результатах RAW поиска реально начинается в кластере ХХХ+yy. То есть имеется смещение yy кластеров.
То же самое есть и у какой то другой пары.
Или, берёшь ранлист другого неоткрываемого файла, прибавляешь это смещение и файл восстанавливается нормально.
Так понятнее?

Цитата:

Так RAW и имя файла - вещи несовместимые же

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

Например, результат RAW поиска в DE:

188-Фирма--ЗАКАЗ УСЛУГИ- (000206967764).doc
192-Natasha--Новости медицины- (000059975060).doc
195-Миша--Мурзилкины загадки- (000208119620).doc

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

tomset, хм, а в какой редакции DMDE выдаётся такая информация?

tomset

Цитата:

Если в файле есть метаданные

Есть такое дело, но не в файловой системе.
И каков процент тех, кто их заполняет в свойствах тех же документов?

The_Immortal
DE - Data Extractor
http://www.acelab.ru/dep.pc/price.php

The_Immortal
DMDE пока так не умеет. Но если автор захочет, сможет сделать.
Только объем работы колоссальный, чтобы разобраться с форматом метаданных различных типов файлов и их версий.

Я имел ввиду DE из комплекса.
Когда все порушено, и такие методы годятся.

К тому же DE умеет создавать виртуальную трансляцию FS, задавая смещения.
Можно найти смещения на нужные места, и большая часть файлов начнет открываться правильно по записям директорий.

Добавлено:
temp9285


Цитата:

И каков процент тех, кто их заполняет в свойствах тех же документов?

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

JPG сортируются по камере и разрешению, что тоже помогает, сразу выбрать нужные фотки.
Список разобранных метаданных файлов постоянно пополняется. Процесс бесконечный. )

tomset

Цитата:

Для .Dос можно брать не только заполненные свойства, а первые слова (заголовок) документа

Можно всё что угодно.
Только что буде в начале документа, в котором заявление на приём (увольнение) . Логично что шапка заявления типа "Генеральному директору ООО "Фирма веников не вяжет". А если таких заявлений 100500, то как их различать по этому методу?

Добавлено:
tomset
DE можно купить отдельно? Будет ли он работать без комплекса?

Цитата:

DE можно купить отдельно? Будет ли он работать без комплекса?

Увы нет.
DE опирается на работу технологических утилит, чтобы читать хреновые диски.
Для построения карты головок, тоже нужен технологический доступ.
Ну и плата выполняет роль ключа для защиты.

Добавлено:

Цитата:

А если таких заявлений 100500, то как их различать по этому методу?

У каждого метода, есть свои плюсы и минусы, но все же лучше чем 123.doc
Может со временем научат задавать переменную структуру, искать где фамилия сотрудника или искать дату в документе.
Предела совершенства нет. )
Зная что нужно искать, можно самому написать нужную структуру для поиска.
Есть и создание своих Grep для любого типа файла и есть редактор структур для поиска чего-то экзотического.

tomset

Цитата:

Увы нет.

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

Добавлено:

Цитата:

но все же лучше чем 123.doc

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

temp9285
Как вариант, есть продукты DDI и Escape у буржуев.
Они больше заточены на работу с нормальными дисками.
Могут использоваться вместе с PC3000 или отдельно.
Но стоят они гораздо дороже чем весь комплекс.
В СНГ цены очень низкие по сравнению со всеми аналогами за бугром.
порядка 1200$.
Не очень долго окупается, если делать заказы по 50-100$

За бугром нет ничего путевого ценой меньше 3 тысяч $$$
Комплекс PС3000+DE в Америке стоит порядка 7000$

Добавлено:

Цитата:

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

Так ни кто кроме разработчиков им толком пользоваться не умеет.
Очень много всего в него напихано. Постоянно меняется и добавляется что-то новое.
Выбрать правильный путь, в какой-то нестандартной ситуации, иногда очень не просто. Но для этого и существует поддержка.
Более того, для решения разных вопросов приходится обращаться к разным разработчикам, так как каждый знает хорошо только свою часть.
Иной раз целый консилиум из 3-4 разработчиков приходится привлекать. )

temp9285
Цитата:

Так понятнее?

Чуть более

Цитата:

1 - в списке файлов есть фото с именем "Мы с Трезором на границе.jpg" и этот файл не восстанавливается в нормальном виде
2 - в результатах RAW поиска имеется фото на котором сфоткан человек с собакой на границе. Все остальные фотки с "котиками"

В общем, среди RAW-списка я нашел тот самый файл "Мы с Трезором на границе.jpg"! Точнее это тот самый docx, который не восстанавливается нормальным образом через восстановление из-под NTFS. Они даже по размеру совпадают (кстати, размер - это ведь реальный сопоставитель - Вы ранее и об этом и говорили). Теперь бы хотелось пофиксить файл в ФС...

NTFS-файл (как правильно называть это не знаю, поэтому буду обзывать так) имеет кластер 56784569.
RAW-файл (как правильно называть это не знаю, поэтому буду обзывать так) имеет кластер 58961957.
Смещение: 2177388.
А теперь надо как-то сделать вот это:
Цитата:

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

Не поясните?

The_Immortal

Цитата:

кстати, размер - это ведь реальный сопоставитель

Реальный, но с оговорками.

Цитата:

NTFS-файл (как правильно называть это не знаю, поэтому буду обзывать так)

Насколько понимаю, речь идёт о файле по данным из записи MFT (ранлист соответствующей записи). Было бы неплохо увидеть дамп записи, скриншот открытия файла и т.д. Если всё так, то смещение имеется. Было бы хорошо ещё одну пару найти.
Ведь сейчас ещё непонятно, то ли запись повреждена, то ли файл реально не туда записался (сдампился). Опять же, посмотреть карту кластеров и сто по ней есть (или нет в кластерах, которые в RAW-поиске.
Я уже писал про ошибки ФС, и если они не были исправлены вовремя (*)
А работа с ФС имеющей ошибки может привести к различным проблемам.
Буквально на днях была ситуация. Человеку записал на флэшку необходимые файлы. И работал с ними (вордовские документы), при сохранении файлов происходила ошибка и файл исчезал. Выяснилось что файлы реально были удалены, но при этом лежали скрытые файлы ~wxxxx.tmp, которые являлись сохраняемыми файлами. Причина была в ошибках одной папки, которая в ТС показывала размер 34 гига, при том что флэшка была 32 а винда в её свойствах показывал что занято всего 13. Чекдиск поправил ситуацию и всё заработало нормально.
(*) Есть те, которые не соглашаются на предлагаемую проверку диска, есть ещё более "крутые" - те вообще отключают проверку дисков, считая что это лишнее.

temp9285, в таком случае, я сейчас сделаю чекдиск, после сниму посекторку и на ней буду уже смотреть. На данный момент я работаю с посекторкой до запуска чекдиска.

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

Цитата:

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

Хорошо, а не подскажешь, а если в уже восстановленных файлах (в изи рековери) попробовать найти, есть ли среди них файлы OTF по данным HEX например. Можно так? Просто у меня чувство, что они вполне там могут быть, но с неправильным расширением...
А скрипты уже проще разобраться и заново написать, чем с такими сложностями восстанавливать. А вот со шрифтами намного сложнее...
PS. Просто твое сообщение перечитал раз десять уже, лазил по ключевым моментам в гугле и... сложно, когда это для меня уже за гранью. Хотя я всегда был с компами на Ты и многим подсказывал и помогал...

dmkov9

Цитата:

попробовать найти, есть ли среди них файлы OTF по данным HEX например. Можно так?

Конечно можно - открываешь файл в хексредакторе (например Hxd) и смотришь какие байты в самом начале. Правильные для OTF-ок написал ранее.

Добавлено.
Если файлов много, то можно поискать что может искать по хексам с учётом расположения сигнатуры.
Если такого нет, то можно ограничить число кандидатов в том же Total Commander. Но в нём сигнатура ищется по всему файлу.

temp9285
ОК. Буду пробовать, тогда отпишусь. Файлов конечно сотни Да, надо было файлы важные блин на облако залить...

temp9285, чек диск [more=сделал]
Код: Обработано свободных кластеров: 19222632.
Проверка свободного места на диске завершена.
В битовой карте тома обнаружено свободное место, помеченное как выделенное.

Windows сделала исправления в файловой системе.
Дальнейшие действия не требуются.

312568640 КБ всего на диске.
235445504 КБ в 106654 файлах.
42380 КБ в 6663 индексах.
0 КБ в поврежденных секторах.
190224 КБ используется системой.
65536 КБ занято под файл журнала.
76890532 КБ свободно на диске.

4096 байт в каждой единице распределения.
Всего единиц распределения на диске: 78142160.
Доступно единиц распределения на диске: 19222633.

The_Immortal

Цитата:

А как высчитать сколько секторов занимает запись, чтобы сделать её дамп?

Размер указан в бутсекторе раздела, но обычно это 1024 байта (2 сектора).

Цитата:

Т.е. по сути chkdsk сделал всё то же самое, что и реконструкция в DMDE

По сути чекдиск сделал констатацию имеющегося.
Он не в курсе содержимого файла, можешь всё содержимое файла прописать "чекдиск лошара" и он не обидится.


Цитата:

Кстати, в RAW-поиске файлы дублируются. Т.е. есть файл с тем же кластером, что и MFT-запись (он, естественно, не открывается) и есть такой же файл (с таким же размером), но со смещением (он открывается).

Я почти не пользовался RAW поиском в DMDE, поэтому не особо в курсе как там всё выглядит (трактуется).


Цитата:

Правда, такое же смещение я пока встретить не могу...

Какое такое? 56784569 или смещение контрольного файла? Если последнее, то получается что ты нашёл ещё одну контрольную пару?

temp9285,
Цитата:

получается что ты нашёл ещё одну контрольную пару?

Цитата:

NTFS-файл (как правильно называть это не знаю, поэтому буду обзывать так) имеет кластер 56784569.
RAW-файл (как правильно называть это не знаю, поэтому буду обзывать так) имеет кластер 58961957.
Смещение: 2177388.

Другие пары имеют другие значения смещений между собой.

В общем, пока на примере одного файла (точнее одной пары). Вот исходный файл, который после восстановления не открывается (см. размер - 145 588 байт). Дамп этой записи.
А вот соответствующие этому файлу файлы из RAW-поиска (см. размер - 145 588 байт). Почему тут их аж 3 копии - мне совсем непонятно (обычно две копии, о чем я писал выше).

f471695719.docx - открывается без каких-либо ошибок. Имеет смещение 2177388 относительно вышеуказанной MFT-записи. Дамп этого файла.
f456992831.docx - открывается с аналогичной ошибкой, что и MFT-запись. Имеет смещение 339527 относительно вышеуказанной MFT-записи. Дамп этого файла.
f454276615.docx - открывается с аналогичной ошибкой, что и MFT-запись. Имеет аналогичный кластер (56784569), что и MFT-запись. Дамп этого файла (хотя он аналогичен дампу MFT-записи).

The_Immortal
В первом случае нужен дамп не сколько заголовка файла а его файловой записи - 114529.
Все дампы переименованы в zip тобой или как? На самом деле видно что там заголовки docx, которые по сути zip архивы. По хорошему, нужно весь файл смотреть. Кстати их можно открыть в архиваторе и протестировать - те, которые пройдут её целы.
И да, в выяснил что в названии файла при RAW-поиске фигурирует номер начального сектора (эта же цифра в ID). Так что это три копии одного файла в разных местах. И в качестве контрольной их использовать нельзя, или можно, но лишь какую то одну пару.