Задача. Восстановить данные из SSD ADATA SU650 240GB.
Описание проблемы. Накопитель не определяется в системе.
Результаты диагностики. Неисправность микропрограммы накопителя: во время инициализации зависает одна из частей микропрограммы, что приводит к невозможности запуска SSD.
Необходимые для восстановления информации процедуры.
Подготовка накопителя к запуску в режиме ROM.
Модификация микропрограммы накопителя и загрузка ее в память SSD.
Запуск накопителя с применением модификаций микропрограммы.
Построение транслятора накопителя.
Копирование данных заказчика.
Результат.
Данные восстановлены полностью.
Особенности заказа.
Особенность этого заказа заключается в том, что накопитель построен на микроконтроллере SM2258XT, который не поддерживается коммерческими продуктами для восстановления информации из твердотельных дисков. Для восстановления доступа к информации требуется загрузка в память диска модифицированной прошивки, которая извлекается из файлов Field Update накопителя, которые можно найти на сайте производителя.
Если прошивку не модифицировать, а просто загрузить в память и запустить, произойдет обновление микропрограммы, одним из этапов которого является pretest — аналог селфскана накопителей на жестких магнитных дисках. Во время pretest, который длится секунды, происходит инициализация (грубо говоря, стирание; хотя процесс на самом деле значительно сложнее, но нам важен результат — данные из ячеек памяти исчезают без возможности восстановления) всех областей NAND-памяти.
Модификация микропрограммы заключается в отключении всех деструктивных для данных этапов ее работы, включая pretest.
Меня часто спрашивают: а чем так опасны эти запилы и царапины на поверхности жесткого диска? Вы же профессионал, наверняка есть технологии, позволяющие вычитать данные и с запиленных или зацарапанных поверхностей — почему вы так их не любите?
Да, конечно, технологии имеются. Но давайте будем объективны: из области запила или царапины данные нам уже не достать, так как в этом месте магнитная поверхность разрушена (конечно же, вместе с данными). Кроме того, вокруг самой царапины определенная область (в каждом индивидуальном случае — своего, индивидуального, размера) не может быть прочитана в силу термического разрушения намагниченности (когда поверхность «пилится», она сильно нагревается и проходит точку Кюри). Наконец, третье, и самое главное — при запиливании или зацарапывании образуется масса мелких частиц (стружка, опилки), которые начинают летать внутри гермоблока и могут находить себе «пристанище» не только на внутреннем фильтре, но также и на поверхностях диска, головках и т.д.
Не стоит забывать и о том, что вычитывание информации с поврежденных поверхностей — значительно более дорогостоящая процедура, чем чтение неповрежденных пластин, в силу применения тех самых технологий (первое) и в силу необходимости использования большего количества запчастей (второе). Накопитель должен быть обязательно очищен от опилок и стружки, которая появилась в нем в результате запиливания.
Об опилках и стружке я и хочу поговорить поподробнее, на одном весьма показательном примере.
Запиленный жесткий диск
Специалист по восстановлению информации с многолетним стажем, такой, как я, относительно легко определяет жесткий диск, в котором происходит процесс запиливания или зацарапывания поверхностей, по звуку. Передать это словами сложно — нужно иметь опыт. Скажем так, звук жесткого диска, который начал запиливаться, начинает разительно отличаться от нормального в сторону шипений, свистов и частых ударов, сливающихся в резонирующие вибрации.
Такой накопитель поступил к нам на днях. При малейшем подозрении на запиливание или зацарапывание накопитель подвергается тщательному осмотру — особенно его блок магнитных головок. Осмотр выявил типичную картину быстро прогрессирующих повреждений.
Нижняя головка (head 0)
Как правило, запиливание диска начинается с одной поверхности, и затем, по мере накопления внутри гермозоны свободно перемещающихся частиц, перекидывается на другие. По статистике, этот процесс чаще начинается или с верхней, или с нижней головки — просто потому, что и та, и другая ограничены с одной стороны (верхняя — крышкой гермоблока, нижняя — его дном) — при соударении с таким ограничителем шансы головки на разрушение гораздо больше, чем при соударении расположенных друг напротив друга головок.
В нашем случае все началось с нижней головки. Образовалось два концентрических запила — первый в зоне парковки, второй — в служебной зоне. Головка, которая работала с этой поверхностью, является самой грязной. Опилками покрыта вся ее поверхность, включая слайдер и кронштейн. Пазы слайдера ими просто забиты.
Такие загрязнения очень опасны, так как при работе головка парит над поверхностью на расстоянии в несколько десятков или сотен нанометров — размер опилок значительно больше, а значит, контакт головки и поверхности (через частицы опилок) неизбежен, что обязательно приведет к увеличению разрушений.
Нижняя головка, с которой, собственно, и начались проблемы диска. Опилками покрыта вся ее поверхность.
Опилки в верхней части слайдера нижней головки накопителя.
Опилки на кронштейне нижней головки накопителя.
Головка 1
Следующая в пакете головка находится с другой стороны магнитной поверхности; это головка 1. Разрушения по ее поверхности намного меньше и имеют явно сгенерированную проблемами по головке 0 природу.
Нижняя поверхность, когда по ней начались разрушения, стала активно продуцировать опилки и стружку; большая часть этих «материалов» оставалась на неисправной поверхности и оседала на ее головке, но вскоре, после того, как объем выделяемых нижней поверхностью частиц превысил критическое значение, они начали распространяться внутри гермоблока. Часть их оседала на фильтре гермозоны, другая часть продолжала «путешествовать» внутри, оседая на головках, поверхностях и стенках гермозоны. По простой теории вероятности, чем ближе к разрушениям расположен объект, тем больше шанс того, что продукты разрушения покроют именно его; именно по этой причине на головке 1, самой близкой к нижней головке пакета, опилок больше, чем на других, расположенных дальше, головках.
Третья сверху головка накопителя (вторая снизу).
Опилки на слайдере второй снизу головки.
Головка 2
Расположенная над головкой 1, головка 2 — вторая в пакете сверху и третья снизу. Она находится в одной пазухе с головкой 1 и, по этой причине, должна иметь примерно одинаковые с ней разрушения. В действительности ее разрушения несколько больше.
Прежде всего, бросается в глаза пучок стружки, имеющийся на этой головке. Кроме того, хорошо видны скопления опилок в углублениях слайдера. Основание слайдера в его вершине относительно чистое (относительно предыдущей головки, конечно).
Стружка — это первый признак зарождающегося запила. Головка срезает с поверхности при соударении длинные ленты лубриканта; эта стружка скапливается в той части головки, которая соприкасалась с пластиной. Опилки образуются, когда эта стружка попадает в промежуток между слайдером и поверхностью; здесь стружка измельчается по принципу абразива, и разлетается отсюда по всему гермоблоку. Также, когда слайдер царапает уже те слои, которые находятся под лубрикантом, он выбивает из них опилки.
Следующая за верхней головка накопителя. Пучок стружки, в области вершины слайдера начинают собираться опилки.
Опилки в верхней части слайдера показанной выше головки.
Пучок стружки на показанной выше головке.
Головка 3 (верхняя)
Головка 3 — самая верхняя в пакете. До нее разрушительное воздействие запила должно дойти в последнюю очередь — собственно, так оно и случилось. Слайдер и кронштейн головки чистые от опилок, но имеется пучок стружки. Верхняя поверхность диска не имеет повреждений, следовательно, эта стружка прилетела сюда снизу, с других головок.
Очевидно, что разрушение третьей головки едва началось, поверхность пока еще чистая, но если бы диск продолжал работать, разрушение этой поверхности было бы вопросом времени. Весьма небольшого времени.
Верхняя головка накопителя. Сама головка чистая, но на слайдере накопился пучок тонкой стружки. Это означает, что по этой головке процесс запиливания еще не начался, но вот-вот начнется.
Пучок тонкой стружки по верхней головке.
Заключение
Что можно сказать в заключение? Бывает, что пользователь, сам того не зная, делает восстановление информации невозможным. Описанный выше случай — один из таких.
Диск вначале начал себя странно вести, срывался с рекалибровки, подстукивал и исчезал из системы. Казалось бы — самое время обратиться к специалисту, но хозяин устройства решил иначе. Первое, что он сделал — это подключение диска через другие разъемы (как питания, так и интерфейса). Это не помогло. После этого была запущена утилита проверки диска (Windows CheckDisk), которая, конечно же, начала свою работу — но на физически неисправном диске завершить ее она не могла, циклично обращаясь в адреса, которые не могли быть прочитаны. Как результат — полуживой диск быстро исчерпал остаточный ресурс, нижняя головка упала на поверхность и начала запиливание. Ну а дальше, по мере накопления внутри гермозоны «пиломатериалов», повредились и остальные поверхности.
Вывод из той печальной истории достаточно прост. Если вы видите, что накопитель ведет себя не так, как обычно; если вы слышите из накопителя незнакомые звуки, которых не было раньше — это повод обратиться к специалисту — как минимум позвонить и поинтересоваться, что может означать текущее поведение диска. Это будет бесплатно и убережет вас от потери информации.
В Международный Женский День 8 марта к нам обратилась одна из крупных организаций города Бишкека с отказавшим RAID-массивом. Массив из 11 SAS-дисков емкостью 900 Гбайт каждый, и в дополнение — двенадцатый диск горячей замены (hot spare). На 11 дисках был собран RAID-5 (странно, но, как говорится, выбор сисадмина священен). Массив перестал работать в ночь на 7 марта, обслуживающий его персонал ожидал сутки в надежде на то, что тот поднимется сам, но чуда не случилось. Массив остался неисправен, так как для запуска ребилда в нем банально уже не хватало участников.
Предстояло выяснить следующее:
Порядок, в котором «уходили» и «приходили» диски массива, поскольку в полке (а массив физически был собран в стандартном blade-server) имелся диск горячей замены.
Последнюю рабочую конфигурацию массива.
Причину выхода массива из строя.
Основная конфигурация массива, к счастью, оказалась доступной через управляющее приложение RAID. Поэтому с размером страйпа (порции данных в секторах, распределяемой по дискам), типом массива и некоторыми другими характеристиками все было ясно исходно. Проблему составлял только состав массива: какие именно диски исключались, какие включались в его состав, и в каком составе он окончательно вышел из строя.
Этикетка сервера.
Работу начали с поиска метаданных массива. Современные дисковые массивы, собранные на серьезных контроллерах, часто несут массу служебной информации, необходимой для функционирования RAID, прямо на дисках. Эта информация может быть как зашифрованной, так и находиться на дисках в открытом виде. Но, в любом случае, она исключительно полезна и должна использоваться в работе по восстановлению данных.
В нашем случае эта информация оказалась частично открытой, частично ее пришлось расшифровывать. Порядок дисков в метаданных хранился в открытом виде, по серийным номерам; статус дисков (активный, не активный, горячая замена) был зашифрован битовыми флагами.
На основании метаданных удалось выяснить, что массив относительно недавно пережил ребилд: из массива был исключен один из дисков, и на его место встал диск горячей замены. Ребилд завершился успешно, и массив продолжил свою работу.
После этого из массива «ушел» еще один диск. С этого момента массив начал работать в весьма рискованном для данных состоянии degraded (деградирован). Что это означает?
RAID-5 — это дисковые массивы с контролем четности, допускающие потерю одного участника массива. При этом блоки четности (XOR-блоки) распределяются на всех дисках массива по определенному алгоритму, как правило — равномерно. Если один из дисков массива исчезает (по любой причине — например, ломается), данные с этого диска восстанавливаются по блокам четности контроллером массива, и массив продолжает работать. Если в массиве предусмотрен диск горячей замены, контроллер включит его в состав массива, при этом будет запущена процедура ребилда — восстановления содержимого исключенного члена массива на основании блоков четности с других дисков.
Однако если диска горячей замены нет, массив начинает работать в деградированном состоянии. Это означает, что исключенный из массива диск воссоздается контроллером на основании блоков четности с остальных дисков, но запаса прочности у массива уже нет — если выйдет из строя еще хотя бы один диск, контроллеру не хватит информации из блоков четности для воссоздания потерянных дисков, целостность данных нарушится, и массив перестанет существовать — контроллер должен будет перевести его в состояние offline.
Фрагмент метаданных поступившего в работу массива
В нашем случае в массив включался один диск, а исключалось из него три. Для корректного восстановления информации требовалось определить, вместо какого диска встал в массив накопитель горячей замены (таким образом определялось, какой диск покинул массив первым); затем следовало определить, какой из двух оставшихся исключенных накопителей был исключен раньше.
С диском горячей замены проблем не было: он оказался в метаданных массива, ведь он был включен в него штатно и, следовательно, был также штатно прописан в метаданные. По его положению в массиве мы определили, какой из исходных дисков был исключен из массива первым. Этот диск был исключен и из анализа.
Статистика (включая карту энтропий) участников массива, фрагмент.
Трехмерная визуализация энтропии одного из дисков массива, в двух разных проекциях.
Для определения наиболее актуального участника массива мы воспользовались наиболее достоверным методом — анализом энтропии. Разные инструменты представляют энтропию данных по разному. В спорных случаях оптимальнее всего использовать несколько методов визуализации энтропии, так как традиционный «плоский» метод может оказаться малоинформативен. Наш случай оказался как раз таким, спорным — так как исключение дисков из массива происходило в течение небольшого времени.
Поэтому, кроме традиционного «плоского» метода визуализации энтропии (гистограммы), мы использовали также трехмерную визуализацию, дающую гораздо более детальную картину распределения данных внутри анализируемого объекта. Результат: менее актуальный диск определен, диски выстроены в массиве в правильном порядке, массив собран и данные доступны.
Данный массив, ввиду того, что все диски массива оказались исправны, был собран нами по цене копирования, по акции «соберем RAID по цене копирования».
Профессиональные карты памяти CFast стандарта 2.0 появились на рынке относительно недавно (более-менее массово их стали использовать в профессиональных камерах, главным образом Canon, с 2016 года). Не смотря на это, они начали попадать в поле нашего зрения практически сразу после выпуска — но всегда с логическими проблемами (удаленные файлы или карта была отформатирована).
Но все течет, все изменяется — и вот в наших руках первая карта CFast 2.0, неисправная физически. Карта не отдает свой ID, не показывает емкость и вообще ведет себя довольно тихо. Увы, другого выхода, кроме как выпаивать NAND-микросхемы и вычитывать их дампы с последующей сборкой образа, у нас нет.
Тут следует сказать пару слов о том, что такое CFast 2.0. Для многих это просто карта памяти Compact Flash, пусть и с другим коннектором. Однако по факту это твердотельный диск (SSD) со стандартным SATA-соединением. Правда, разъем питания отличается от SATA, но это не мешает устройству по факту оставаться SSD в SATA-исполнении.
Что это значит для нас? Стандартная сборка дампов для этого накопителя невозможна, необходимо использовать алгоритмы, характерные для SSD.
Карта памяти CFast 2.0 Lexar 128 GB, поступившая к нам в работу
Пришедшая в работу карта CFast 2.0 Lexar 128 GB построена на довольно проблемном контроллере SM2246XT — сборка данных на этом контроллере имеет свои сложности, и довольно часто — фатальные для данных. Особенно, когда микросхемы памяти вычитаны с проблемами.
В нашем случае память прочиталась хорошо, а битовые ошибки были почти полностью скорректированы механизмами ЕСС. Мы получили «чистые» дампы в количестве 16 штук (в нашей карте 4 NAND-микросхемы, в каждой микросхеме по 4 банка) по 4 Гбайт каждый.
Карта CFast 2.0 Lexar 128 GB внутри
Коннектор карты CFast 2.0
NAND-микросхема из карты памяти CFast 2.0 Lexar 128 GB (BGA 152)
Для восстановления информации с этой карты пришлось комбинировать два инструмента. Дампы памяти считывались с использованием PC-3000 Flash через специализированный адаптер (BGA-152/132). В этом же комплексе производилась первоначальная обработка дампов (коррекция с использованием ЕСС и перечитывание нескорректированного). После этого дампы были перенесены в PC-3000 SSD, где проводились дальнейшие работы по восстановлению данных.
Еще даже не закончилась праздничная неделя нового года, а нам уже пришлось восстанавливать информацию. Да, приходится работать даже в выходные и праздники. Как сказал бы Мандалорец, «таков путь».
В первые дни 2020 к нам обратились со следующими устройствами: 3 жестких диска, две флешки и один iPhone. Расскажу кратко о каждом.
Первый жесткий диск привезли из города Ош — информация нужна была быстро, так как без нее встала работа целой организации. Пришлось подсуетиться и между тостами за праздничным столом (диск приехал 31 декабря еще прошлого года) произвести замену блока магнитных головок и вычитывание диска. Работу удалось выполнить в стахановском режиме всего за сутки, ровно в новогодние праздники: 31 декабря 2019 и 1 января 2020.
Второй жесткий диск — ноутбучная Toshiba. Ноутбук упал во время работы, и диску хорошо досталось. Восстановление данных оказалось возможным, хотя также, как и в первом случае, потребовало хирургии: замена блока магнитных головок.
Третий диск, хвала богам, физически не пострадал. Это оказалась также, как и в предыдущем случае, ноутбучная Toshiba, доставшаяся ее текущему владельцу по наследству от умершего родственника. Требовалось выяснить, какие файлы были удалены после того, как владелец компьютера отошел в мир иной, когда это было сделано, и по возможности восстановить эти файлы. Работа не простая, но вполне выполнимая.
Теперь об iPhone. Очень интересный случай. Аппарат абсолютно исправен, но при обновлении не смог обновиться и выдал соответствующую ошибку. Владелец запаниковал и побежал в ЦУМ, где ему произвели самый простой и доступный в этом случае тип сервиса: обновление прошивки через компьютер («восстановление»). Но поскольку первоначально обновление закончилось ошибкой, ЦУМовский «специалист» просто стер аппарат и перепрошил его как новый. Естественно, все данные при этом были утеряны безвозвратно. Пришлось восстанавливать аппарат из резервной копии, которая была создана программой iTunes на компьютере пользователя перед тем, как он начал обновлять свой iPhone. Почему он сам не восстановил телефон из резерва? Выше я написал — он запаниковал, и напрочь забыл о том, что у него есть эта резервная копия =).
Первая флешка в Новом году оказалась 32 Гб монолитом производства HIKVISION. Увы, монолит оказался абсолютно мертв, и без распайки или разводки его на Spider Board восстановление данных с него невозможно. Заказчик забрал флешку до лучших времен — восстановление с нее информации — дело не из дешевых, так как и производитель еще малоизвестен (а значит, пинаут монолита придется выяснять опытным путем), и само исполнение (монолит) требует использования дорогостоящего оборудования.
Вторая флешка 2020 оказалась попроще: microSD с удаленными файлами. Их удалось восстановить почти все.
Поздравляем вас с наступившим Новым годом и желаем не терять ваши данные!
Радиальные царапины от неудачных попыток заказчика самостоятельно вывести задранные головки.
Очередной заказ на восстановление информации, увы, из категории «безнадежный». Диск прибыл во вскрытом состоянии и с весьма плачевным состоянием поверхностей. Головки сорвало в парковочной зоне (скорее всего, упор позиционера деформировался, что привело к удару слайдерами об ось шпинделя). В парковочной области образовался концентрический запил.
Такие типы запилов (тем более, в парковке) можно обойти. Это не просто, но возможно (модифицируется программа старта накопителя, который, вместо того, чтобы проводить полный цикл запуска с рекалибровкой, просто позиционирует головки в нужное нам место). Если бы проблема была только с запилом в парковочной зоне, за данные можно было бы еще повоевать.
Но, увы, заказчик решил самостоятельно демонтировать блок магнитных головок (для чего, сформулировать не смог). Работал без защиты от пыли и грязи, на обычном письменном столе. Как результат: отпечатки пальцев на поверхностях (что в целом не страшно и может быть убрано) и (что намного хуже) несколько радиальных царапин неправильной формы.
Радиальные царапины полностью исключают возможность использования донорского блока магнитных головок, так как при каждом вращении головки неизбежно попадут в область турбулентности, генерируемую царапиной, очень быстро перегреются и выйдут из строя. Кроме того, неизбежны микротравмы поверхности выбиваемой из этих царапин пылью.
Вердикт: восстановление данных невозможно.
Отпечатки пальцев на поверхности. Заказчик работал без соблюдения элементарной чистоты.
Сегодня к нам в лабораторию поступил довольно любопытный диск. Нет, вначале мы подумали, что это будет рядовой, заурядный заказ — Western Digital на 500 Гбайт, ничего вроде бы особенного, но… При подключении диска к ПАК РС-3000, после вывода диска на интерфейс, оказалось, что его емкость 320 Гбайт, а серийный номер диска при идентификации отличается от того, который написан на этикетке.
Тщательный осмотр показал: гермоблок накопителя относится совсем к другому семейству. Судя по этикетке, диск должен быть Tahoe и иметь явственно выраженные ребра по краям крышки гермозоны. По факту же накопитель оказался из семейства Rider с соответствующим строением крышки.
Собственно, те, кто подделал накопитель, особенно и не скрывали своей активности. Торцевая этикетка накопителя, дублирующая серийный номер, даже не была отделена от печатной основы — мы легко удалили ее, и нашему взору предстала оригинальная, исходная этикетка с серийным номером.
Вполне логично спросить: а для чего наклеивать на накопитель емкостью 320 Гбайт этикетку, на которой указано 500? Кто знает… Судя по истории этого компьютера, был он куплен давно, в те времена, когда такая разница в емкости была существенной по деньгам. Поэтому, думается, меркантильный интерес тут самый оправданный.
Задача. Восстановить данные с переломленной флешки.
Описание проблемы. Флешка имеет физическое повреждение: переломлена.
Результаты диагностики. Методом визуального осмотра определено, что флешка переломлена в области соединения USB-разъема.
Необходимые для восстановления информации процедуры.
Распайка разъема USB на монтажной плате.
Напайка проводников для соединения флешки и USB-разъема.
Проверка соединения.
Включение флешки в штатном режиме, копирование данных заказчика.
Результат.
Данные восстановлены полностью.
Особенности заказа.
Такие заказы обычно не являются сложными, так как возможность привести устройство к состоянию «чтение в штатном режиме» всегда лучше, чем восстановление информации в технологическом режиме.
Задача. Восстановить данные с разбитого мобильного телефона Philips Xenium W6500.
Описание проблемы. Телефон подвергся серьезному физическому воздействию, экран разбит.
Результаты диагностики. Телефон частично исправен: на звук включается. Принято решение восстанавливать данные без распайки eMMC.
Необходимые для восстановления информации процедуры.
Перевод телефона в режим Recovery.
Снятие графического ключа.
Рестарт телефона в нормальном режиме.
Получение root-доступа.
Установка в аппарат необходимых утилит.
Клонирование телефона в файл, извлечение данных из полученного файла-образа.
Результат.
Данные восстановлены полностью.
Особенности заказа.
Основная сложность при выполнении данного заказа заключалась в том, что у телефона не работает дисплей. Получить доступ к информации можно было двумя способами: установить новый модуль дисплея (в силу старости аппарата, его пришлось бы ждать от недели до двух), либо клонировать аппарат по USB. Было принято решение идти по второму пути, так как он был очевидно быстрее. Для загрузки в телефон нужных приложений использовался отладочный режим. Удачей было то, что в телефоне уже был включен режим разработчика и отладка по USB; если бы этого не было, возможен был бы только первый вариант, либо выпаивание микросхемы памяти и прямое ее чтение.
