Восстановление USB LuxMini 320 ( История восстановления "флешки" с элементами детектива. )

OS: Debian GNU/Linux Squeeze и Microsoft Windows XP.
Hard: USB Silicon Power Flash Drive LuxMini 320 объёмом 4G (серия D33B29).

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

Вводим палочку в соответствующее ей отверстие и смотрим, что имеем:



Имеем что-то с китайским разрезом глаз. "Флешка" явно из бракованной партии, вывезенной по направлению на свалку, успешно перехваченной предпринимателями второго эшелона, перепрошитой в полуподвале на улице с непроизносимым для русского (да и немца, наверное) названием и почти "в белую" ввезённой в Казахстан. Эти "silicon-power" в качестве имени производителя, пустые идентификаторы модели и модификации... Ну не верю я, что такое сделают в ходе нормального производственного цикла. Хорошо, хоть VID и VIP оставили неизменными, чтобы мы могли не разбирая устройство, выяснить, что за чип используется в качестве контроллера.


Контроллер "флешки" отвечает на запросы системы, а вот далее дело не идёт. Из каких-то соображений контроллер не желает сообщать никаких подробностей об устройстве памяти, которым он управляет. Вульгарно выражаясь, можно выдвинуть предположение о том, что контроллер живой, а вот накопитель сдох. Но мы то знаем, что устройство новенькое и явно заблокировано в результате игры на нём неумелых шаловливых ручек.

Продолжим расследование. "lsusb -v", "hdparm /dev/sdX", "fdisk -l /dev/sdX" и "badblocks /dev/sdX" лишь укрепляют мои подозрения о том, что устройство в норме, а доступа к памяти нет потому, что контроллер его нам не предоставляет.

Марш-бросок по просторам "интернета" дал мне сведения о том, что чип контроллера есть "Phison PS2251-50". Идём на сайт производителя чипа:


Читаем, читаем, читаем и - бинго, волшебное словосочетание: Support IEEE 1667.

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

А было так. Новенькую "флешку" воткнули в Microsoft Windows Seven. Та обнаружила, что чип устройства поддерживает свежеиспечённый протокол IEEE 1667 ("Standard Protocol for Authentication in Host Attachments of Transient Storage Devices", "Стандартный протокол аутентификации при подключении съемных устройств хранения данных"). Windows поинтересовалась, а не желает ли пользующий её задать пароль доступа к устройству, раз уж появилась такая возможность. Что бы и не ответить утвердительно на вопрос, сути которого не понимаешь? - многолетняя практика нажимания "yes" и "accept" на любой запрос берёт своё. Что-то нажали, что-то ввели, поигрались и успешно забыли всё, что сотворили. При следующей загрузке "тупое" устройство не приняло вводимый в ответ на запрос "главный пароль", который "забыть никак не возможно", так как он заучен наизусть за много лет использования на всех почтовых ящиках и сайтах. Даже "Линукс" не "опознал" устройство - это приговор, "флешка гонит" - путь на полку.

В общем, устройство заблокировано контроллером, даже не инициализирующим микросхему памяти, пока не будет введён верный пароль. В Linux поддержки "IEEE 1667" пока нет. Единственный способ сделать так, чтобы всё заработало - перепрошить контроллер, вытащить с "сырого" устройства всё, что можно и отформатировать его так, чтобы оно опознавалось любой операционной системой.

Дальнейшее рысканье в "интернетах" дало мне пакет утилит, предназначенных для работы с чипами Phison. В лучших традициях индийского и китайского программного обеспечения для Microsoft Windows выяснить, откуда "это" и кто "это" сделал не вышло. На сайте производителя чипа ссылку на скачивание утилит восстановления я не нашёл. Надо полагать, их высылают на запросы компаний дилеров, а от-туда они уже разлетаются по форумам и сайтам поддержки.

Чтобы далеко не ходить, выкладываю пакет у себя:


Запускам "MPALL_F1_7F00_DL07_v308_00.exe". Подключаем "флешку" (устройство необходимо подключать именно после запуска приложения):


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


Можно указать чип контроллера вручную, а можно и отдать это на автоопределение:


Параметры устройства хранения, опять-таки, подаются корректировке, при желании:


Явно указываем сколько и какого типа разделов на устройстве мы желаем получить. Утилита удивляет богатством конфигураций, но мне нужна просто "флешка", без всяких там виртуальных CD-ROM и тому подобного, потому - выбираем режим одного раздела на всё устройство:


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


И вот то, зачем всё затеяно - отключаем поддержку IEEE 1667:


Сохраняем настройки:


После сохранения настроек жмём "Start":


Выдыхаем:


Проверяем результат:


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

Зачищаем область разметки:



Даём системе команду пересоздать блочное устройство:


Запустим утилиту разметки блочных устройств и создадим на нём один единственный раздел FAT32 (type: 0B):


Проверям, появился ли новый раздел на устройстве:



Устанавливаем пакет поддержки работы с файловыми системами FAT:


Форматируем раздел в FAT32:


По завершению форматирования переподключаем "флешку" и смотрим, что у нас получилось: