Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Подробнее (2 ukv) 11.03.02 15:11 Число просмотров: 2254
Автор: ukv Статус: Незарегистрированный пользователь
|
|
Мое мнение - файл потерян. Если автоматическое восстановление удаленного файла не привело сразу к успеху, шансов уже мало. А если это еще к тому же бинарный файл, да размером больше чем на сотню кластеров ... Шансы только теоретические, да и то при условии, что все кластеры удаленного файла все еще свободны. Предположим, что это так. Можно даже как-нибудь автоматизировать процесс составления разных цепочек кластеров, но сравнивать эти цепочки на соответствие желаемому результату похоже можно только вручную (под виндами монтировать зашифрованный диск и смотреть, сколько каталогов/файлов выглядит нормально. Кстати, при монтировании не выдается никаких ошибок? даже итоговой контрольной суммы у этого файла нет?) Пусть на проверку одного варианта уйдет пара минут. За месяц можно перебрать 10,000 вариантов, если сидеть не разгибаясь. А сколько свободных кластеров на диске (даже без учета удаленного файла)? И сколько в этом файле может оказаться скачков в цепочке кластеров? На один скачок придется перебрать в среднем половину оставшихся свободных кластеров. Зная размер файла и свободное место на диске, можно было бы прикинуть трудоемкость такой работы. Если вариантов окажется ближе к миллиону - ручной перебор отпадает. А как автоматизировать проверку целостности файла, не зная его формата - я не знаю.
|
|
<software>
|
Помогите! (Проблемы с файловой структурой) 06.03.02 14:09
Автор: L_Alien Статус: Незарегистрированный пользователь
|
Если кто сталкивался с подобной проблемой, подскажите, плиз.
В один непрекрасный день из корня С исчезли все нескрытые файлы (именно файлы, а не папки), среди прочих и зашифрованный монтируемый диск (Jetico BestCrypt container). Запустив Unerase из-под ДОС, восстановил (как удалился - непонятно, кроме меня, никто доступ к компу не имеет)
Но тут обнаружилась другая проблема. В восстановленном файле при монтировании обнаружились свои проблемы - с файловой системой. На этот раз уже не в корне, а в директориях следующих уровней. Вместо привычных названий была куча пиктографических символов с самыми невероятными размерами и датами создания. Если кто видел когда-нибудь такое - знает: зайти в эти не то файлы, не то папки невозможно.
Заподозрил ФАТ. Запустил DiskEditor. Он, ясен пень, руганулся на кучу ошибок.
Но обе копии FAT оказались верными. Посмотрел повнимательнее. И в возрастающей цепочке чисел обнаружил одно место, где вместо полагающегося по порядку 3-хзначного кластера стоял пятизначный!
Проблема в том, что DiskEditor запускается в Виндах только на чтение. А прога для монтирования диска именно виндовая.
Подскажите, как можно откорректировать FAT? И восстановится ли все путем изменения номера кластера? Опыта работы с системными разделами диска у меня никакого.
|
|
Результатов нет 28.01.03 13:46
Автор: L_Alien Статус: Незарегистрированный пользователь
|
За те мгновения, что удавалось выкраивать в прошлом году, обнаружил следующее.
1. При просмотре фат ошибка далеко не в одном месте, а в нескольких.
2. Принудительное исправление путем перебивания цифр в ФАТ ничего не дало.
3. Возникло подозрение, что процесс исправления порчи, к сожалению, не симметричен. Т.е. если при восстановлении удаленного файла были неправильно соединены цепочки кластеров, то перебивать фат после монтирования результатов не даст. Т.е. нужно, чтобы изначально в исходном .jbc файле были верны выстроены кластеры. А неверный файл монтирвоать и править - бесполезно. Не знаю, насколько верно предположение.
Если так, то ситуация грустная. :-( Нужно в FAT32 постоянно менять номера кластеров в файле. После каждой правки монтировать файл и смотреть, восстановилась ли исходная структура папок.
Вопрос: возможно ли это? Т.е. как в фат меняются номера (в фат16 структура была другая, тут через одну цифру нули)? И можно ли как-то этот процесс автоматизировать. Потому как пробовать туеву хучу вариантов...
|
|
Эххх, хороший был диск :(((( 06.03.02 17:25
Автор: ukv Статус: Незарегистрированный пользователь
|
Судя по описанию, дело худо. Если я правильно помню, есть только один простой способ убрать из каталога кучу файлов: в директории в начале какой-нибудь записи поставить нулевой байт - и остальная часть каталога просто не будет анализироваться. Если произошло что-нибудь подобное, останется куча "лишних" цепочек в фат (правда, без пересечений). В этом варианте не все так плохо - цепочки можно восстановить, но тогда непонятно, что именно сделал Unerase. Вроде unerase работает, когда первый кластер восстанавливаемого файла свободен (т.е. файл был действительно удален) - вариант скверный, т.к. большой фрагментированный бинарный файл восстановить практически невозможно. Плюс к тому все происходило под виндами - нет никакой гарантии, что все кластеры от удаленного файла все еще свободны. За этот "плохой" вариант говорит и то, что начало шифрованного диска все же видно.
По поводу скачка в номерах секторов: это относится к восстановленому файлу? и как выглядит скачок:
100, 101, 102, 55555, 104, 105,
100, 101, 103, 55555, 104, 105,
В первом случае - возможна ошибка в фат, можно попробовать заменить номер на 103, хотя скорее всего файл просто продолжается с кластера 55555, а в кластере 103 - уже совсем другой файл. Второй случай может запросто получиться при автоматическом восстановлении файла, если кластер 102 был уже занят. Это почти приговор. У меня когда-то грохнуласть часть фат (в обеих копиях), и мне не удалось восстановить ни одного фрагментированного .zip - хотя это теоретически возможно (в зипах есть CRC и по идее зип можно собрать кластер за кластером) - но это теоретически. На практике - файл можно считать потерянным.
|
| |
Подробнее (2 ukv) 07.03.02 17:32
Автор: L_Alien Статус: Незарегистрированный пользователь
|
> Судя по описанию, дело худо...
Видимо, я все описал несколько суетливо и бестолково. Сейчас подробнее.
27.02. - обнаружил, что в корне диска С нет файлов autoexec.bat, config.sys, Scandisk.log и disk_f.jbc. С перепугу запустил ndd32 из Norton Utilitis. Она начал исправлять кучу ошибок. К счастью, я создал файл отката и отыграл назад. Но не все отыгралось. Например, папка "Мои документы" почему-то осталась как $o$$o$~1. Пришлось вручную возвратить правильное название. За исключением нее еще 2 папки вручную переименовал. Но это все. На файлах как будто бы это никак не отразилось.
После этого запускал ue32. Он ничего не нашел.
28.02. - загрузившись с дискеты, запустил DiskEditor. И он показал, что в корне С есть искомый файл с удаленной первой буквой имени: *isk_f.jbc. Тогда элементарно запустил unerase и восстановил его и прочие config.sys. Ребутнулся, примонтировал свой F: - смотрю, корень в порядке. Заглянул в первую попавшуюся папку - тоже все есть.
(Кстати, дата удаления была - 20.02.)
2.03. Когда понадобилось поработать с диском F, то обнаружил, что в трех других папках F дело обстояло не так благополучно, как уже описывал: куча хлама вместо имен вложенных папкок и файлов. Запустил DiskEditor, но не имея никакого опыта работы, мне это мало что дало. ыЕдинственное, что сумел найти через DiskEditor - ошибку в обеих (идентичных, кстати) FAT. А ошибка такая в порядке номеров кластеров: ..., 374, 13622, 376, ...
Ни Unerase, ни ndd32 в диске F я не запускал! (Да там и бесполезно.)
Теперь какие есть подозрения.
1. С момента удаления и до того, как я восстановил .jbc-контейнер, прошло 8 дней! Несколько раз за это время комп включался. Возможно, что содержимое кластеров, содержащих нужный файл, перезаписывалось другими файлами. Но тогда, вроде бы, он не должен был восстановиться вообще, поскольку цепочка кластеров удаленного файла disk_f.jbc была бы нарушена безвозвратно.
2. Удаление файлов из диска С - дело рук вируса (сам не удалял, никто к компу не подходил, да и удалить файл под виндами - не так-то просто, встроенная утилита его защищает. Если только удалить сам BestCrypt), и тогда удаленные файлы вполне могли повредиться.
Как версия - файлы из С:\ потерялись из-за глюка бессмертного творения Б.Г. :-)
3. Во время удаления или глюка повредился сам контейнер (при восстановлении не очень верю - см. п.1). Но вот что именно: область данных или только FAT...
Я надеюсь, что только FAT. При остальном раскладе вряд ли что-то смогу сделать. Правда, и с FAT никогда не работал. Поэтому обращаюсь здесь к более опытным людям, кто встречался с подобными проблемами.
|
| | |
Подробнее (2 ukv) 28.01.03 17:09
Автор: amirul <Serge> Статус: The Elderman
|
> 27.02. - обнаружил, что в корне диска С нет файлов
> autoexec.bat, config.sys, Scandisk.log и disk_f.jbc. С
> перепугу запустил ndd32 из Norton Utilitis. Она начал
> исправлять кучу ошибок. К счастью, я создал файл отката и
> отыграл назад. Но не все отыгралось. Например, папка "Мои
> документы" почему-то осталась как $o$$o$~1. Пришлось
У меня такое было. Это ndd (помню в незабвенном творении про НашегоBOFH-а они назывались Norton Disk Destroyer :-))) ) начудил, после того как в config.sys-е (его ж просто не было) при загрузке не установилась правильная кодовая страница.
> обнаружил, что в трех других папках F дело обстояло не так
> благополучно, как уже описывал: куча хлама вместо имен
Это тоже бывшие русские имена :-)))
Самое главное, что по крайней мере содержимое таких файлов ndd не @#$ит
По поводу всего остального ничего конкретного - одни подозрения, причем такие же как у тебя.
|
| | |
Подробнее (2 ukv) 11.03.02 15:11
Автор: ukv Статус: Незарегистрированный пользователь
|
|
Мое мнение - файл потерян. Если автоматическое восстановление удаленного файла не привело сразу к успеху, шансов уже мало. А если это еще к тому же бинарный файл, да размером больше чем на сотню кластеров ... Шансы только теоретические, да и то при условии, что все кластеры удаленного файла все еще свободны. Предположим, что это так. Можно даже как-нибудь автоматизировать процесс составления разных цепочек кластеров, но сравнивать эти цепочки на соответствие желаемому результату похоже можно только вручную (под виндами монтировать зашифрованный диск и смотреть, сколько каталогов/файлов выглядит нормально. Кстати, при монтировании не выдается никаких ошибок? даже итоговой контрольной суммы у этого файла нет?) Пусть на проверку одного варианта уйдет пара минут. За месяц можно перебрать 10,000 вариантов, если сидеть не разгибаясь. А сколько свободных кластеров на диске (даже без учета удаленного файла)? И сколько в этом файле может оказаться скачков в цепочке кластеров? На один скачок придется перебрать в среднем половину оставшихся свободных кластеров. Зная размер файла и свободное место на диске, можно было бы прикинуть трудоемкость такой работы. Если вариантов окажется ближе к миллиону - ручной перебор отпадает. А как автоматизировать проверку целостности файла, не зная его формата - я не знаю.
|
| | | |
2 ukv 14.03.02 09:26
Автор: L_Alien Статус: Незарегистрированный пользователь
|
> Кстати, при монтировании не выдается никаких ошибок? даже
> итоговой контрольной суммы у этого файла нет?)
Монтируется нормально. Насчет контрольной суммы не знаю, не видел там такого.
Единственное, что смог проверить - это не изменился ли его размер после восстановления. Создал точно такой же файл (то бишь пустой контейнер). И сравнил размер в байтах пустого и моего восстановленного. Одинаковые.
Типа есть надежда, что Unerase восстановил его нормально, то есть содержимое этого зашифрованного контейнера повредилось не при восстановлении файла. Тогда не знаю, в чем дело.
> Пусть на проверку одного варианта уйдет пара минут. За месяц можно
> перебрать 10,000 вариантов, если сидеть не разгибаясь. А
> сколько свободных кластеров на диске (даже без учета
> удаленного файла)? И сколько в этом файле может оказаться
> скачков в цепочке кластеров?
Дохлый номер. Вот уж чего-чего, а времени свободного у меня нет :-( - сам бы покупал его на зарплату, если бы это было возоможно. Да и чтобы чувствовать себя среди цепочек кластеров как рыба в воде, мне пришлось бы обложиться книгами и мануалами и изучать физическое строение винта :-)
Короче, льщу себя надеждой, что все дело в повреждении обеих копий фат, а все остальное в порядке. Правда, даже если так, попробуй еще фат восстанови...
|
|
Пытаюсь помочь 06.03.02 15:19
Автор: Yurii <Юрий> Статус: Elderman
|
> Но обе копии FAT оказались верными. Посмотрел
> повнимательнее. И в возрастающей цепочке чисел обнаружил
> одно место, где вместо полагающегося по порядку 3-хзначного
> кластера стоял пятизначный!
Если разница в номерах кластера на единицу, то просто поставь следующий по порядку. Если есть разброс, то можно поэкспериментировать. Если разброс велик, то посмотри по содержимому кластеров в этом диапазоне. Ищи содержимое, похожее на содержимое "правильных" предыдущих кластеров (т.е. которые точно содержат контейнер от BestCrypt). Только не забудь записать на бумажку то число, которое там сейчас записано, вдруг понадобится для отката.
> Проблема в том, что DiskEditor запускается в Виндах только
> на чтение. А прога для монтирования диска именно виндовая.
Загрузись в режиме эмуляции MS-DOS или с системной дискеты.
Можно еще попробовать команду lock, которая обеспечит прямой доступ к диску (смотря какая у тебя винда).
> Подскажите, как можно откорректировать FAT? И восстановится
> ли все путем изменения номера кластера? Опыта работы с
> системными разделами диска у меня никакого.
Ты нормально описал проблему, думаю поменять цифирки не составит труда. А восстановится или нет, покажет только эксперимент.
|
| |
Есть софта, под винды в реальном времени все правит.. хоть Фат32 хоть НТФС (билды разные).. ссылу не помню, могу выслать. 06.03.02 22:18
Автор: !mm <Ivan Ch.> Статус: Elderman
|
|
|
| | |
Плиз, если не трудно 07.03.02 17:43
Автор: L_Alien Статус: Незарегистрированный пользователь
|
Вышли, плиз, если не трудно.
Кстати, у этого зашифрованного контейнера-диска фат16.
|
| | | |
Выслал 12.03.02 11:41
Автор: !mm <Ivan Ch.> Статус: Elderman
|
> Вышли, плиз, если не трудно.
> Кстати, у этого зашифрованного контейнера-диска фат16.
на looking_for@inbox.ru
|
|
|
подробно о проекте
Анализ криптографических сетевых...
