Восстановление данных в России и СНГ
Малая Пироговская, 18с1, офис 406
В будние дни 9:00-21:00, в выходные 11:00-18:00

Ваш город - Москва?

Круглосуточный телефон

Ложно-софтовые проблемы на флешках. Проблемы с флешками, из-за которых не открываются файлы

В нашей практике восстановления флешек мы часто сталкиваемся с тем, что какой-то файл на флешке не открывается. Иногда это может быть не один, а несколько файлов, целые папки или разделы. Обычно это софтовые проблемы — следствие каких-либо программных сбоев. Решаются они различными програмными средствами. Но бывает и так, что любые программы окажутся бессильными, так как причина глубже. Флешка может лишь «выглядеть» работающей правильно, когда на самом деле именно в ее некорректной работе и таится корень зла. Вот о таких ложно-софтовых проблемах и пойдет речь в этой статье.

Incorrect password or not a TrueCrypt volume. Вот с каким сообщением TrueCrypt’а столкнулся наш очередной клиент при попытке подмонтировать свой файл-контейнер с секретной и, конечно, очень важной информацией.

Примерный (с учетом цензуры) смысл негодований несчастного был таким:

— Как это неверный пароль?! Ввожу каждый день с закрытыми глазами!!! Как это не трукриптовский том??!! Он самый! Любимый avi-файл на 1,5 Гб, в котором совсем не видео!

В чем же дело?! Файл находился в числе прочих данных на USB-flash Silicon Power 2 Гб. По словам клиента, все остальные документы в порядке. Никогда никаких проблем с флешкой не было. Работу всегда заканчивал корректно и вообще берег ее, как зеницу ока.

На первый взгляд состояние флешки абсолютно рабочее. Сам файл на уровне файловых таблиц FAT жив-здоров: копируется и просматривается. Однако при попытке монтировать в TrueCrypt видим:

556x471xlozhno-softovye-problemy-na-fleshkah-ris1-incorrect-password-or-not-a-truecrypt-volume.jpg.pagespeed.ic.PRvqWzT1UD

Слава Богу, владелец флешки рассудил здраво и не стал делать тайны из своего пароля, позволив нам работать, проверяя все версии.

Анализ FAT на флешке никаких ошибок не выявил. Старая добрая R-Studio и подобные средства восстанавливают файл ровно таким же образом, что и простое копирование. Значит, проблема в самом файле.

Иногда так может происходить даже из-за незначительных повреждений контейнера. Достаточно повредиться заголовку. И тогда спасти может только использование резервного заголовка, хранящегося в самом контейнере. Проверить эту версию нетрудно: в меню Mount Options отмечаем соответствующие галочки (работаем только с копией файла):

566x479xlozhno-softovye-problemy-na-fleshkah-ris2-use-backup-header-embedded-in-volume-if-available.jpg.pagespeed.ic.hpakICTVxI

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

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

310x389xlozhno-softovye-problemy-na-fleshkah-ris3-hex-contents.jpg.pagespeed.ic.MM1p0rlo6K

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

Лучше займемся следующей гипотезой. Предполагаем, что содержимое файла изменено не на программном, а на аппаратном уровне. В этом случае то, что мы видим является результатом некорректной работы контроллера, отвечающего за чтение и запись. И в таком случае то, что нам «показывает» флешка, вовсе не обязательно совпадает с «правильным» содержимым памяти.

При этом «устойчивость результата» ничего не доказывает и не опровергает. Контроллер действительно может выдавать одинаковый, но не соответствующий действительности результат при каждой попытке чтения.

Решать такую проблему можно, воспринимая носитель как нерабочий, с диагнозом «неисправность контроллера». Сначала делаем резервный образ флешки со всеми данными. Для посектороного клонирования используем WinHex.

Далее флешку надо разбирать, отпаивать чипы памяти, считывать ее на программно-аппаратном комплексе (мы используем Flash Extractor v6.141) в дампы. Считанные дампы содержат множество ошибок, которые исправляются ECC-коррекцией. Затем, имитируя правильную работу контроллера программным образом необходимо расшифровать полученные дампы и получить корректный имидж-файл, то есть образ флешки. Извлекаем наш контейнер из этого образа. Пробуем монтировать в TrueCrypt.

И Ура!!! Контейнер примонтировался!!! Буква логическому диску присвоилась, но содержимое пока не открывается.

332x123xlozhno-softovye-problemy-na-fleshkah-ris4-net-dostupa-fajl-ili-papka-povrezhdeny-chtenie-nevozmozhno.jpg.pagespeed.ic.VhxurZnEIF

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

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

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

Следует отметить, что этот случай не является каким-то исключением. Флеш-накопители действительно часто дают подобные сбои. Просто не всегда это проявляется именно таким образом. Всем понятна ситуация, когда флешка вообще не работает, как устройство. Тут соблазна самому себе помочь не так много. А если она совсем, как живая, просто файлик повредился. Например, *.doc, *. хls или база данных 1с. Иногда таким образом «повреждается» не файл а таблица размещения файлов (FAT). Тогда флешка будет вести себя, как носитель с логической проблемой — файл копируется, открывается с ошибкой или не открывается вовсе. И неопытный восстановитель может не понять, почему же софтовые средства (chkdsk, fsck, r-studio, easy recovery) не помогают.

К сожалению, часто бывают фатальные ошибки. Например, таким ложно-софтовым образом поврежденный файл некоторые пытаются «чинить» стандартными MS-средствами или пробуют натравить Chkdsk на «поврежденный» FAT. Все это наверняка приведет к записи на флешку. И очень вероятно, что сектора флешки, которые по вине контроллера всего лишь «отдавали» неправильное содержимое, теперь действительно будут перезаписаны белибердой. И даже заботливо сделанный посекторный клон такого носителя не будет его настоящей резервной копией, так как не позволит вернуть саму флешку в прежнее состояние.

Поэтому желающим спасать себя самостоятельно нужно запомнить всего одно правило: если вы хотите попробовать различные средства восстановления при «софтовых» проблемах на флешке, сделайте предварительно ее образ, например, WinHex’ом. И экспериментируйте тогда именно с этим образом, а не с оригиналом. Если проблема действительно логическая, то вы прекрасно справитесь с ней, работая над клоном. А если ее софтовость окажется ложной, вы, хотя бы, не ухудшите шансы на восстановление данных аппаратными средствами.

Вячеслав Мочалов, 28 марта 2011 года

Похожие услуги:

Закажите восстановление данных

Закажите бесплатную диагностику

na