<![CDATA[Восстановление данных с неисправных носителей информации HDD FLASH SSD и ремонт ноутбуков в Волгограде]]>

<![CDATA[Восстановление данных с неисправных носителей информации HDD FLASH SSD и ремонт ноутбуков в Волгограде]]> https://www.itcvg.com/ RU Mon, 16 Mar 2020 02:07:00 -0400 Incomedia WebSite X5 Professional imfeed <![CDATA[Дисковая хирургия, или как избежать непоправимого]]> imblog

Начну, пожалуй с грустного... Многие годы у меня не выходит из головы один случай...

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

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

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

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

Пациент:

Yarra_5400 ST500LT012-1DG142, ёмкостью 500Gb

Анамнез:

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

Изначально диск был отдан заказчиком "знакомому программисту", который даже успел поставить диагноз "залипание" и предложил примерно такой-же сценарий, как и изложенный выше... Однако у заказчицы возобладал здравый смысл и она передала накопитель одному из наших партнёров, а тот в свою очередь нам.

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

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

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

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

Но мы снимем блок голов и осмотрим его детально. Важно снять блок голов так, чтобы магнитный слой поверхности дисков остался неповрежденным. Каким образом это делается - наш небольшой секрет и ни на одном "обучающем видео из интернета" вы этого не найдете. На фото ниже видно, подвесы покалечены настолько, что если "просто вывеcти головы на парковку" и влючить, как делают на видео в интернете, то поверхности дисков будут зацарапаны моментально, а при повреждениях магнитногого слоя неизбежно будут и потери в данных. А если БМГ не снять, то невозможно будет оценить состояние нижнего подвеса, который к слову оказался деформирован еще больше, чем верхний... Вобщем таким комплектом много не начитаешь ;-)

Однако, не смотря на всю серьёзность, конкретная ситуация с залипанием определенно положительна. Залипание голов по сути спасло пользовательские данные. Ведь если-бы головки не смогли прилипнуть и заблокировать запуск двигателя, то буквально несколько попыток включения с завязанными в узел подвесами похоронили-бы пользовательские данные окончательно.

Блок голов мы будем менять на исправный донорский. Замена блока голов - процедура тоже не тривиальная. Тут как в медицинской трансплантологии - не каждый накопитель подойдет и не каждый комплект голов будет совместим. Методики подбора донорских голов мы также не разглашаем.

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

Возможно получилось немного скучновато, но на мой взгляд весьма познавательно. Выводы как всегда делать Вам, уважаемые пользователи.

Любое копирование, цитирование и публикация материалов (или их части) допускается только с разрешения администрации сайта и с обязательной ссылкой на источник.

]]> Mon, 16 Mar 2020 06:07:00 GMT https://www.itcvg.com/blog/?diskovaja-hirurgija-ili-kak-izbezhat-nepopravimogo https://www.itcvg.com/blog/rss/000000010 <![CDATA[Не бейте ваш диск!]]> imblog

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

Точнее вопрос нам задают всегда примерно один и тот-же, с одним смыслом, который можно разделить на два ключевых момента:

1. Почему диск сдох?

2. Как избежать поломки в дальнейшем?

Забегая вперед скажу, что в 99,99% случаев вина за выход диска из строя лежит на пользователе. Да-да, в основе лежит несоблюдение пользователями правил эксплуатации дисков.

Например, на крышке каждого диска имеются предостеригающие надписи, порой снабжённые картинками для наглядности. Но, как показывает практика, мало кто обращает на это внимание...

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

Пациент:

Seagate Rosewood_A5 ST1000LM035-1RK172, ёмкостью 1Tb

Анамнез:

Двигатель диска стартует, после чего из гермоблока доносятся щелчки. Через какое-то время двигатель останавливается. Диск при этом не определяется.

Для специалиста понятно, что проблема кроется в неисправном блоке магнитных голов (БМГ) и для восстановления данных данных необходима его замена на донорский.

Вскрываем гермоблок диска и осматриваем головы на предмет повреждений.

С пьезиками всё в порядке. Слайдеры тоже чистые и подвесы не деформированы.

Однако этот комплект голов не видит даже серворазметку и не может спозиционироваться, не говоря о том, чтобы прочитать с поверхности хоть что-нибудь.

После замены родного блока голов на исправный донорский, диск отдал весь необходимый заказчику объём данных. Потери оказались незначительные, в виде нескольких не важных файлов. Видео с фрагментом работы над этой задачей под названием "Читаем Rosewood" доступно по ссылке.

Но давайте пойдем дальше и попытаемся выяснить причину гибели диска. А поможет нам в этом анализ состояния S.M.A.R.T. и просмотр лога событий. Давайте сразу поставим точки над "и" и внесём ясность.

S.M.A.R.T. попросту - это система мониторинга. Бытует ошибочное мнение, что S.M.A.R.T. предсказывает время выхода накопителя из строя. Это как раз было-бы великолепно, но к сожалению это не соответствует действительности. S.M.A.R.T. отображает только ТЕКУЩЕЕ состояние диска, т.е. показатели в данный момент времени и ничего больше. Что это за система мониторинга рассказано здесь https://en.wikipedia.org/wiki/S.M.A.R.T.

Ни каких прогнозов, опираясь на показания S.M.A.R.T., увы сделать не возможно. Можно только оценить состояние накопителя на ТЕКУЩИЙ момент.

В данном случае мы видим, что накопитель пребывает в плачевном состоянии. Критичные параметры отмечены красным цветом.

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

Наличествует еще один критичный параметр, который имеет ненулевое значение. Это датчик ударных нагрузок (параметр 191). Судя по его состоянию можно смело утверждать, что при жизни с диском обращались не очень аккуратно.

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

Как видно из логов, диск начали "бить" уже с первых часов эксплуатации ноутбука, в котором он стоял. Думаю многим будет любопытно узнать, что происходит внутри гермоблока при ударных нагрузках. В конце заметки находится официальное видео от производителя дисков и ссылка на его источник (эпизод про удары и их последствия начинается примерно с 3 мин.) Настоятельно рекомендую это видео посмотреть от начала и до конца.

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

Пожалуй на этом можно закругляться...

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

https://youtu.be/rYUoFhoXiOU]]> Mon, 20 Jan 2020 04:25:00 GMT https://www.itcvg.com/blog/?ne-bejte-vash-disk https://www.itcvg.com/blog/rss/00000000F <![CDATA[Ремонтируем JPG]]> imblog

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

В каких-же случаях, спросите Вы, могут помочь наши возможности восстановления поврежденных картинок? Элементарно. Представьте ситуацию, Ваш жесткий диск "посыпался", и Вы в надежде сэкономить пошли не в профильный сервис по восстановлению данных, а предположим к "знакомому программисту". Через какое-то время Вам возвращают окончательно убитый диск, с которого уже не возможно ничего восстановить от слова "совсем" и некоторое количество "спасённых" фотографий. Почему в кавычках? Да потому, что начав просмотр результатов такой халтуры (словом "работа" язык назвать не поворачивается) Вы приходите в ужас - все фотки отображаются со сдвигами и в искаженном цвете.

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

Что делать, спросите Вы, если уже случилось то, что случилось? Ответ простой - ремонтировать имеющееся. Другого варианта просто нет.

Идея разработки собственного инструмента возникла после того, как нами был опробован целый ряд профильного коммерческого программного обеспечения для этих целей. Программы были разные, дешёвые, дорогие, очень дорогие... Но в процессе использования выяснялось, что заявленные возможности этих программ оказывались весьма преувеличены. Названия программ не привожу, ибо это будет уже реклама или антиреклама... Если хотите убедиться сами - гугл в помощь ;-)

Позвольте представить Вам пару примеров наших возможностей. Слева - битая фотография, справа - фотография после ремонта.

Если Вы внимательно посмотрите на отремонтированные изображения, то увидите точки расхождения, которые Вы самостоятельно можете замаскировать в любом графическом редакторе, хотя-бы при помощи инструмента "Клонирующая кисть"

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

Обращайтесь, мы будем рады помочь и вернуть Вам мгновения из прошлого :-)

]]> Thu, 14 Feb 2019 17:08:00 GMT https://www.itcvg.com/blog/?remontiruem-jpg https://www.itcvg.com/blog/rss/00000000E <![CDATA[Имена файлов стали непонятными, программы для восстановления данных не помогают]]> imblog

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

Вот и к нам в очередной раз обратился заказчик с такой проблемой.

Пациент:

SD Card Transcend SDHC Class 10, ёмкостью 16Gb
Анамнез:

Карта памяти компьютером определяется корректно, открывается, но практически не содержит файлов. А те файлы, что есть имеют странные названия и не открываются. Пробовали самостоятельно сканировать карту различными программами для восстановления файлов - в итоге ни один найденный файл не работает. Отдавали в несколько сервисов - результат нулевой. Необходимо восстановить несколько видеороликов.

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

Итак приступим... Для начала необходимо убедиться, что всё действительно плохо и карта в интерфейс отдаёт мусор. И что это не является проявлением вмешательства операционной системы в работу накопителя. Карта была подключена мимо ОС непосредственно к порту комплекса для восстановления данных, сделана посекторная копия пользовательской области в образ и проведен анализ, который в свою очередь показал, что наиболее вероятной причиной недоступности данных пользователя является запредельное количество битовых ошибок и неспособность штатного механизма коррекции ЕСС в микрокоде их устранить. Следовательно дальнейшая работа с накопителем по интерфейсу теряет всякий смысл.

На картинке ниже видно, что фактически накопитель отдал по интерфейсу.

Идём дальше... Выпаиваем микросхемы NAND и считываем их в дампы. Дальнейшая работа будет производиться только с ними. Про распайку и сборку мной было достаточно рассказано в предыдущих статьях. Только для начала необходимо получить приемлемое качество этих дампов (без битовых ошибок).

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

Только радоваться результату было рановато... Видеороликов в заданной папке не оказалось. Среди удаленных файлов их тоже не было. Хотя довольно приличный объём с точки зрения файловой системы был чем-то занят. Сигнатурный анализ этого пространства показал в нём наличие заголовков видеофайлов искомого типа.

И здесь начинается самое интересное... Есть несколько особенностей формирования и хранения этих видеофайлов. Файл состоит из заголовка и контейнера, а контейнер может состоять из нескольких фрагментов. Так вот все эти составляющие (и заголовок и все фрагменты контейнера) должны лежать в определенном порядке и никак иначе.

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

1. Не соблюдён порядок следования частей, из которых они состоят.

2. Части наверняка будут принадлежать разным видеофайлам.

3. Добвьте к этому искаженное содержимое секторов с данными (как при работе по интерфейсу) и получите нерешаемый ребус.

В моём случае видеофайлов было не много и все они были собраны вручную. Вишенкой на этом тортике стала демонстрация результатов работы заказчику.

Какие из всего этого можно сделать выводы?

1. Оценка невозможности восстановить данные далеко не всегда объективна. Степень достоверности зависит от уровня компетенции специалиста, дающего такую оценку.

2. Если вы хотите только попытаться восстановить данные - можете обращаться куда угодно.

3. А если вам действительно необходимо восстановить данные - то следует обращаться к нам.

]]> Sat, 19 Aug 2017 07:23:00 GMT https://www.itcvg.com/blog/?imena-fajlov-stali-neponyatnymi,-programmy-dlya-vosstanovleniya-dannyh-ne-pomogayut https://www.itcvg.com/blog/rss/00000000B <![CDATA[Припаяйте мне разъём!]]> imblog

Довольно частенько к нам обращаются люди с казалось-бы тривиальной просьбой:

- Есть флешка с оторванным разъёмом. Припаяйте мне разъём, пожалуйста.
- Зачем?
- Хочу данные восстановить...
На предложение обратиться в другой сервис (я ни при каких условиях не возьмусь "просто припаять", без 100% уверенности, что результат не отразится в худшую сторону на данных пользователя или на устройстве) - следует вполне ожидаемый ответ:
- Да был я уже в нескольких сервисах - ни хрена они не могут...
Или с более экзотической просьбой:
- Вы-же занимаетесь микропайкой? Восстановите мне дорожки на плате.
И предъявляют переломленную пополам флешку или карту памяти... И ведь люди не учитывают, что платы эти многослойны и цена такой работы наверняка будет превышать стоимость восстановления данных непосредственно с микросхем памяти.

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

К сожалению так бывает не всегда и простой подход не приносит ожидаемый результат.

В данной заметке мы рассмотрим один из таких случаев.

Пациент:

UFD (USB Flash Drive), производитель не известен (предположительно Apacer), ёмкость накопителя не установлена.

Контроллер Phison PS2251-50-F

На борту одна микросхема памяти в формфакторе LGA-52

Интерфейс USB 2.0

Анамнез:

В результате точного пинка ногой - корпус флешки развалился, а сама флешка приняла Г-образную форму. Из видимых повреждений имеем отломанный интерфейсный разъем. Также повреждена (вырвана) часть проводников на печатной плате. Отдавали в несколько сервисных центров, где флешку пытались починить. Безрезультатно. Задача извлечь из накопителя базу данных.

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

Вот только ни один из паяльных дел мастеров не обратил внимание на еле заметную деформацию платы в месте, куда припаяна микросхема памяти.

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

Значит для восстановления данных потребуется микропайка, ибо использование специализированного ZIF-адаптера для вычитывания содержимого NAND, увы не представляется возможным. Решение по обеспечению отсутствующих контактов было принято оригинальное, а именно напайка тонким проводом с выведением в отверстия специального переходничка LGA-52 -> TSOP-48.

После распайки микросхема отдала коректный ID и объем в 4Gb.

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

Собственно это будет правильная маска XOR и Interleave.

Интересным для меня этот случай стал по другой причине. Если при сборке образа использовать специализированный алгоритм построения транслятора (читай автомат), то в результате строится вполне адекватное дерево каталогов с корректными данными. Только как выяснилось в последствии, в структуре каталогов отсутствует та самая нужная папка, ради которой всё и затевалось.

Пришлось пойти другим путем и собирать образ по номеру блока с использованием маркеров. В результате такой реконструкции обнаружился и каталог-потеряшка вместе с нужной базой данных.

Использование транслятора - данные восстановлены не полностью

Сборка по номеру блока - данные восстановлены в полном объеме

Задача решена, заказчик доволен. Единственный побочный момент - потеря времени в сомнительных сервисах.

Если Вы столкнулись с подобной проблемой, то положите на одну чашу весов призрачную надежду и мнимую экономию, а на другую гарантированный результат и сэкономленное время. Что перевесит? Думаю, что здравый смысл! Обращайтесь к нам и мы восстановим ваши утраченные данные.

P.S. На десерт ещё немного искалеченных пользователями флешек и карт памяти.

]]> Thu, 08 Jun 2017 20:02:00 GMT https://www.itcvg.com/blog/?pripayajte-mne-razyom https://www.itcvg.com/blog/rss/00000000A <![CDATA[Почти криминальная история]]> imblog

Обратилось в нашу организацию одно из государственных предприятий. Сгорел компьютер. «В дым сгорел, полностью!», сказал представитель этой организации, «А там - архиважная информация!». И конечно-же, в единственном экземпляре... Нужно во что-бы то ни стало восстановить с него данные. Посмотрев на системный блок компьютера — я в душе посочувствовал заказчику. И на ЭТОМ железе до сих пор работают наши госпредприятия ???

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

Пациент:

Western Digital Mammoth WD400JB-00FMA0, емкостью 40Gb

Анамнез:

Диск не подает ни каких признаков жизни.

Восстановить нужно папку со спец. ПО и базу данных для этой софтины. Даже семейство этого жесткого диска говорящее - «мамонт», и год выпуска этак 2004-й от Рождества Христова. По всем прикидкам он пережил своих собратьев минимум лет на семь...

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

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

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

Открутив плату электроники, обнаружилось следующее..

Дыра в CPU и дыра в микросхеме управления двигателем и блоком головок. Вот вам поговорка «сгорел на работе» в действии. Проверив цепь питания предусилителя-комутатора, расположенного внутри гермоблока выяснилось, что преамп в состоянии КЗ. Печально... В данном случае заменой одной лишь платы не обойтись. Помимо платы необходима замена БМГ.

Согласовав с заказчиком сумму и сроки, я приступил к выполнению работ по восстановлению данных.

Когда данные были успешно извлечены в полном объеме — я обратил внимание, что дата последнего доступа к файлам на этом накопителе значилась полутора годами ранее! А ведь компьютер вышел из строя несколько дней назад! Определенно здесь что-то не так...

Я позвонил заказчику, чтобы выяснить какие именно файлы и папки нужны в первую очередь и где они располагаются. Заказчик внятно рассказал: что, где и в каком виде лежит. И тут я впал в ступор... Данных, о которых говорил заказчик не было и в помине. Зато в избытке была другая информация, которая явно указывала на то, что этот жесткий диск не принадлежит предприятию заказчика. Да и представитель заказчика утверждал, что системный блок они до нас ни куда не возили. Мистика какая-то... Как такое могло произойти?

Пришлось совместно провести небольшое расследование. В итоге все оказалось довольно банально и просто. После того, как этот многострадальный системник в последний раз порадовал своих хозяев фейерверком с дымовой завесой, сотрудник отдела, не поставив в известность начальство, самостоятельно отнес его знакомому частному мастеру. Этот «мастер» смог только констатировать факт выхода из строя БП, который в свою очередь спалил и остальное. Вот только этот предприимчивый молодой человек во время диагностики поменял чудом выживший HDD на заведомо неисправный. При повторном визите к этому «горе-мастеру», мастер поначалу пытался всё отрицать. Но после предъявления ряда неопровержимых доказательств и обещаний "привести собаку с милицией", был возвращен назад по-сути украденный им жесткий диск. К счастью вся информация оказалась на месте. Однако заказчику пришлось оплатить наши услуги в полном объеме.

Подводя итог по этому случаю, хотелось-бы предупредить незадачливых клиентов - доверяйте восстановление данных только специалистам в этой области. А «предприимчивых» мастеров предостеречь от необдуманных поступков. Вспомните золотые слова - "Всё тайное - всегда становится явным".

]]> Wed, 15 Jun 2016 07:03:00 GMT https://www.itcvg.com/blog/?pochti-kriminalnaya-istoriya https://www.itcvg.com/blog/rss/000000009 <![CDATA[Восстановление данных с карты памяти. Распаивать или нет?]]> imblog

В этой статье речь пойдет о восстановлении данных с карты памяти и сюрпризах, с которыми пришлось столкнуться в процессе работы. Написать данный материал, меня сподвиг, на первый взгляд, рядовой классический случай. А именно накопитель на основе NAND-памяти. Обычная SD-карта, с классическими симптомами логических разрушений на уровне файловой системы.

Пациент:

SD-карта Kingmax SDHC Class10, емкостью 16Gb

Анамнез:

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

Многие скажут - «Ну и что здесь уникального? С таким случаем справится любая программа для логического восстановления данных.» Точно так-же подумал и я, тем более, что в моем арсенале есть все необходимое для такого рода случаев. Сразу была создана посекторная копия этого накопителя. Заглянув в Boot-сектор, я обнаружил корректное описание логического раздела FAT32. И после анализа таблиц FAT — получил адекватную на первый взгляд структуру каталогов и файлов. Только радость от проделанной работы была преждевременной. Львиная доля фото оказалась не читаемой, а большинство папок — пустыми, что наглядно показано на картинке. Про контроль корректности заголовков файлов и папок мной было рассказано в одной из предыдущих заметок.

Если заглянуть в содержимое такого файла, то кроме нулей там не будет ничего. Иными словами — результат неудовлетворительный.

Здесь я сделаю небольшое лирическое отступление. Ведь по логике вещей раздел есть, файлы есть, а то что они пустые — значит так записались. Или повредились в момент выхода флешки из строя. И такой ответ слышат многие пользователи, обращающиеся в случайные сервисы за восстановлением данных. Самое печальное, что подобного рода ответ устраивает большинство. И человек смиряется с потерей своих данных, принимая такое заключение как истину. И в специализированные DR-сервисы потом обращаются лишь единицы.

На самом деле существует принципиально другой качественный подход к восстановлению данных с флешек и карт памяти. Это так называемая «распайка».

Условно, из устройства выпаивается микросхема(ы) памяти, считывается содержимое на специальном устройстве, выполняется коррекция полученных дампов (EСС), производятся необходимые преобразования и собирается образ.

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

После вскрытия корпуса этой карты памяти, взгляду предстала такая картина. Как видно на фотографии, устройство имеет следы коррозии и окислов.

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

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

После выпаивания микросхема подключается в устройство для считывания (NAND Reader).

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

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

В данном случае это XOR и интерлив. Вот так к примеру выглядит «заксоренный» заголовок jpg-файла (слева), а так после верного XOR-преобразования (справа).

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

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

Выбор за Вами, доверить восстановление данных случайным людям с непрогнозируемым результатом или обратиться к квалифицированным и знающим мастерам, т.е. в нашу лабораторию ;-)

]]> Wed, 25 May 2016 19:42:00 GMT https://www.itcvg.com/blog/?vosstanovlenie-dannyh-s-karty-pamyati-raspaivat-ili-net https://www.itcvg.com/blog/rss/000000008 <![CDATA[Если вирус "пошалил" и зашифровал файлы]]> imblog

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

Недавно в нашу организацию обратился заказчик с винчестером, с которого необходимо восстановить данные.

Пациент:

Hitachi HTS545050B9A300, емкостью 500Gb

Анамнез:

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

Задача восстановить информацию, а точнее семейный фотоархив с диска "D".

Оценка текущего состояния этого жесткого диска показала, что с ним обращались не очень аккуратно, чему свидетельствовало наличие в логах SMART огромного количества ошибок, возникших вследствии ударных нагрузок. Также пользовательский дефект-лист (G-List) был заполнен, что называется "под завязку". Также было выявлено неустойчивое чтение по головам 0 и 2 (всего головок у данной модели 4). Причем неустойчивые области чтения располагались преимущественно там, где нужные пользователю данные не располагались.

На первый взгляд вполне себе "классический кейс" с проблемной поверхностью и полудохлым БМГ. Отключив фоновые процессы обработки дефектов микромрограммой накопителя, я приступил к задаче. MFT нужного раздела была вычитана и где это было необходимо - реконструирована. Взгляду предстала вполне адекватная структура пользовательских данных. Дальше была построена карта цепочек нужных клиенту файлов. И необходимый массив был успешно вычитан (в том числе с использованием технологического режима чтения для полудохлых голов).

Для удобства в работе над заказом по восстановлению данных, в DE комплекса (DataExtractor) реализована возможность контроля заголовков файлов и папок. Проверка осуществляется по характерным сигнатурам заголовков и соответствию папок записям в MFT (Master File Table). Если проверка на корректность проходит успешно, то на объекте появляется зеленая отметка, что наглядно изображено на картинке справа.

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

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

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

При просмотре любого такого файла открывается одно и то же изображение с таким вот содержимым...

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

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

Расшифровка теоретически возможна, но при наличии хотя-бы тела этого вируса. Анализ системного раздела диска результа не принес, т.к. операционная система была явно переустановлена намного позже периода активности вируса. Это наглядно видно на папке профиля пользователя. И заказчик говорил о том, что ОС переустанавливалась несколько раз.

Вот так "классический кейс" плавно перешел в категорию по стоимости и срокам сравнимой с проектированием и постройкой космического челнока многоразового использования. Результат беспечности пользователя и пренебрежение элементарными правилами антивирусной защиты.

В заключении хочу дать несколько рекомендаций, чтобы потом не было мучительно больно:

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

Использовать антивирусное программное обеспечение ДО появления возможных проблем, а не после их возникновения.

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

]]> Mon, 17 Aug 2015 17:26:00 GMT https://www.itcvg.com/blog/?esli-virus-poshalil-i-zashifroval-fajly https://www.itcvg.com/blog/rss/000000006 <![CDATA[К чему приводят попытки сэкономить на восстановлении диска]]> imblog

Однажды просматимвая ветки общедоступных компьютерных форумов, в коих бурно обсуждаются вопросы винторемонта и натыкаясь на посты типа "...есть винт! HELP!!!!" и "...принесли жесткий. Чё делать?", возникла мысль написать статейку, цель которой оградить рядового пользователя от появления еще больших проблем, когда при выборе мастерской по восстановлению информации заказчик руководствуется единственным критерием - дешевизной и не задумывается о том, имеется-ли у человека необходимое оборудование и обладает-ли он определенными знаниями и опытом.

Ведь для привлечения клиентов у такого "мастера" есть только один аргумент - низкая цена. И клиент даже не догадывается, что именно происходит после того, как он отдал свой HDD в руки такому "мегаспециалисту"... А происходит примерно следущее... - "мастер" лезет в интернет и начинает пробовать всевозможные команды и "метОды", какие удалось найти в свободном доступе. Порой даже не понимая их назначения и не задумываясь о последствиях. Или на какой-нибудь форум с вечным вопросом "Что-же делать?" в надежде получить пошаговую инструкцию. А получив кучу советов - принимает их как прямое руководство к действию. Дело в том, что реальные специалисты заходят на такие форумы редко. Общаются они как правило на закрытых специализированных ресурсах или ведут между собой личную переписку.

Вот мне и вспомнился один из клиентов, который стал жертвой таких ремонтёров. Ярчайший пример того как не стоит поступать, если потерянная информация имеет для Вас ценность.

Пациент:

Seagate Pharaoh ST500DM002-1BD142, емкостью 500Gb

Анамнез:

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

Нужно восстановить информацию.

Для специалиста сразу становится понятно, что корень проблемы кроется в развалившемся трансляторе, когда пользовательская область корректно читается только до определенного логического сектора (LBA). Такие последствия возникают только после неверных действий по приведению в чувство "больного" и скорее всего тот знакомый "мастер" знает лишь одно лекарство для ремонта жестких дисков фирмы Seagate архитектуры F3 - это так называемый "пересчёт"... Таких псевдоспециалистов в нашем сообществе именуют "мухобоями", которые командой перечсёта пытаются чинить всё. Большинству этих граждан даже не ведомо назначение этой команды, а о последствиях применения они не задумываются вовсе... Ну да бог с ними, с "мастерами"... Разгребать их рукоблудие все равно приходится нам, скромным инженерам... Для того, чтобы пользовательские данные стали доступны в полном объеме, нужно этот самый транслятор привести в надлежащий вид. Система трансляции накопителя весьма сложная штука и корректность работы этой системы зависит от множества факторов. Взять к примеру дефект-листы этого жесткого диска. Здесь я немного упрощу, для лучшего понимания. Есть заводской дефект-лист, в котором хранится таблица дефектов, выявленных при производстве данного HDD. И есть дефект-лист пользовательский, таблица которого заполняется во время его эксплуатации. Так вот транслятор должен учитывать не только уже имеющиеся дефектные зоны, но и появляющиеся в процессе эксплуатации. На самом-же деле дефект-листов гораздо больше и назначение их разнообразно. И взаимосвязаны они между собой и с транслятором настолько плотно, что даже одна закравшаяся в записи ошибка или не правильная запись способна развалить всю систему. Да и это только верхушка айсберга...

Когда заказчику была оглашена цена и примерные сроки восстановления данных с диска, его реакция была вполне ожидаемой (ведь он уже был у знакомого "специалиста"). "Я подумаю." сказал клиент и пошел думать. Под понятием "подумаю" подразумевается судорожный поиск места, где смогут сделать подешевле и желательно побыстрее. Ведь клиент услышал диагноз - это ТРАНСЛЯТОР.

Через довольно продолжительное время в офисе раздался телефонный звонок. Я даже сразу не сообразил, о чем пытается мне поведать звонящий. Из сбивчивого рассказа понятно было только, что клиент хочет обратиться к нам повторно. Привез человек уже изрядно разукомплектованный девайс.

Сразу бросился в глаза отсутствующий интерфейсный разъем. Также не соответствовала маркировка платы, т.к. в этом поколении HDD Seagate семейства Pharaoh, используется другая серия и ревизия контроллеров. Про отсутствие одного винта и сорванные головки остальных я скромно промолчу, поскольку здесь видно невооруженным глазом работу "мастера", у которого даже торкса нужного калибра под рукой не оказалось... Но был и один существенный плюс - гермоблок не открывали.

Дальше было интереснее. Когда я открутил плату от гермоблока, моим глазам предстала следующая картина... Здесь no comments...

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

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

Но в данном случае сработало "золотое правило". А правило это простое: прежде чем производить с диском какие-либо манипуляции, необходимо зарезервировать с него служебную информацию (содержимое ПЗУ, служебные модули, конфигурационные страницы и т.д.) А поскольку этот диск уже приносили, то SA данного накопителя была автоматически сохранена. Сверив серийный номер на гермоблоке с серийником из нашей базы я убедился, что жесткий диск тот-же самый, какой и приносил клиент в свой первый визит в нашу лабораторию по восстановлению данных. Шанс на благополучное извлечение информации пользователя был.

При других обстоятельствах восстановить данные с этого жесткого диска было-бы не возможно, т.к.

1. На плате отсутствавала микросхема ПЗУ, а в ПЗУ содержатся уникальные для каждого диска параметры (адаптивы), именно для каждого диска, а не для семейства или модели. И подобрать совместимые адаптивные параметры фактически невозможно.

2. Да и шансов, что на "не родной" плате была-бы впаяна микросхема ПЗУ с "родным" содержимым примерно один на миллион.

Подготовив нужную донорскую плату, я подключил диск к диагностическому орудованию. Диск стартовал и в статус-регисрах появилось вечное "занято", а в терминальном логе старта я увидел следущее:

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

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

После загрузки совместимого микрокода, хард выдал уже более бодряшее сообщение.

Проанализировать содержимое SA из под совместимой FW, конечно не получится, но на данном этапе работы с диском этого и не требуется.

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

При реконструкции модуля транслятора, диск сообщил, что реконструировать нечего и создал новый модуль. А после перезапуска, самостоятельно вышел на работу по SATA интерфейсу.

На следующем этапе нужно загрузить уже "родную" версию микрокода, чтобы можно было проанализировать служебную область в полном объеме. На картинке слева видно, что процедура завершилась успешно.

После очередного переключения питания, накопитель вышел в готовность, о чем радостно отрапортавал в терминальном логе старта.

А на команду Get ID диск отозвался правильной моделью с корректным LBA.

Пришло время заглянуть в содержимое служебной области...

Открыв в HEX-редакторе несколько модулей служебной информации этого накопителя, можно было встретить только паттерн 0х00h. Все сомнения были развеяны. Служебная область диска была отформатирована. При всем при том, что подобного рода команды для работы со служебкой не валяются в свободном доступе, как потенциально опасные, не только для хранящейся на диске пользовательской информации, но и как способные вывести из строя само устройство. Сразу вспомнил, что на просторах интернета, один из мастеров описывал возможности формата SA, как средство решения ряда проблем. И сейчас этот опус передается как былина из уст в уста, и среди начинающих и среди уже начавших... Только после публикации того материала, количество невинно убиенных HDD заметно прибавилось, потому как некоторые пытливые умы докопались-таки до синтаксиса "заветной" команды (или продвинутый друг подсказал), а вот что потом делать... Ну что-то я отвлекся от темы... Вобщем после записи необходимых объектов служебной информации назад, этот жесткий диск вернулся в состояние "Status Quo". Наградой моим трудам стало содержимое MBR, неоднозначно указывающее, что данные пользователя на месте.

Дальше для восстановления данных пользователя в полном объеме, необходимо восстановить правильную работу транслятора. После восстановления транслятора стал доступен и весь диапазон LBA. Информация с диска была восстановлена, а заказчик остался доволен результатом. А ведь такой случай встречается один на миллион. И не имея зарезервированной служебки, на кейсе можно было-бы поставить крест. Подводя итог, повторю, слишком низкая цена на услуги восстановления данных - серьезный повод задуматься о качестве этих услуг. В данном случае я так и не смог найти логическое объяснение тому, чем руководствовался человек, решив отформатировать служебную зону этого диска. Но видимо, замена платы электроники на заведомо неисправную и разукомплектованную, была попыткой скрыть уже совершенные деструктивные действия. Чтобы не стать жертвой действий подобных псевдомастеров, доверяйте такую работу специалистам. Наша компания с радостью будет готова вам помочь.

]]> Tue, 12 May 2015 13:06:00 GMT https://www.itcvg.com/blog/?k-chemu-privodyat-popytki-sehkonomit-na-vosstanovlenii-diska https://www.itcvg.com/blog/rss/000000007 <![CDATA[Восстановление информации с накопителя, имеющего BAD-сектора]]> imblog

В этой заметке мы рассмотрим один из случаев восстановления пользовательской информации с жесткого диска, имеющего нечитаемые сектора (в простонародии называемые BAD-блоками или "БЭДАМИ"). Также я постараюсь максимально доступно объяснить разницу между профессиональным и дилетантским подходом к решению такой проблемы.

Пациент:

Seagate Pharaoh ST31000528AS, емкостью 1Tb

Анамнез:

С диска перестала загружаться ОС. При загрузке система падает в BSOD. При подключении диска к другой машине - зависает. Попытка создания посекторной копии на другой носитель к успеху не приводит (тоже виснет). При этом диск нормально определяется в BIOS.

С диска нужно восстановить информацию (документы пользователя).

На первый взгляд ничего сложного нет, но это ошибочное мнение.

Грамотным подходом в этом случае будет:

1. Зарезервировать служебную информацию накопителя.

2. Свести к минимуму обращение к сбойным областям жесткого диска (об этом будет рассказано подробнее).

3. Не производить тестирование поверхности и не пытаться спрятать дефектные сектора в резервную область, т.к. в них может содержаться пользовательская информация. И как правило так оно и есть :-)

4. Не позволять жесткому диску заниматься "самолечением", что достигается изменением части микрокода HDD.

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

Следующим этапом будет чтение MFT (Master File Table). Подробнее о том, что это за зверь, можно почитать здесь:

https://ru.wikipedia.org/wiki/Master_File_Table

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

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

Далее нужно будет построить карту секторов, принадлежащих ТОЛЬКО (!) пользовательским данным, которые необходимо восстановить. Тем самым читать мы будем только те сектора, которые содержат данные, а не весь диск целиком (минимум обращений к поверхности HDD). Построив карту, мы начинаем непосредственно процесс вычитывания данных. Алгоритм работы реализован таким образом, что при обращении к сектору диска-пациента, он автоматически копируется на диск-приемник. А это означает, что повторных обращений к прочитанным секторам уже не будет и фактически работа будет вестись уже с копией.

Чтение осуществляется в несколько этапов по принципу:

1. Сначала сектора, что читаются без проблем (штатно)

2. Потом сектора, что читаются с задержками, но не "сваливают" HDD в ступор. И здесь как раз необходим механизм оперативного управления головками диска.

3. Сектора, которые не читаются

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

Но тут есть один важный момент. Запись на диск, с которого необходимо восстановить данные HE ДОПУСТИМА !!!

На картинке ниже представлен участок диска, с важными пользовательскими данными, содержащий не прочитанные сектора (отмеченные черным и красным).

Эти сектора необходимо прочитать. Для этого я воспользовался так называемым технологическим режимом чтения или "чтением с использованием активной утилиты" (по классификации ПАК PC-3000) - неким особым механизмом, позволяющим прочитать содержимое сектора, если прочие попытки были тщетны. Как это работает - не расскажу, ибо это плоды трудов и долгих исследований многих людей, за что им нужно сказать спасибо.

На следующей картинке представлен результат такой работы.

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

Итогом стало полное восстановление пользовательской информации с данного жесткого диска без потерь и нарушения целостности файлов. Вобщем радость заказчика не знала границ.

А теперь расскажу вкратце о случае с подобным диском, только предварительно побывавшем в руках "горе-мастеров" ...

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

Вобщем после недели издевательств над этим хардом - вернули, сказав мол "всё, бобик сдох". Тем не менее взяли с клиента оплату (верх наглости), мотивировав тем, что работали не покладая рук, потратили время, но поделать ничего не смогли.

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

Когда я позвонил в ту "чудо-контору" чтобы выяснить, что конкретно делали с этим диском - удивился еще больше. Поначалу они даже не смогли вспомнить кто именно из сотрудников занимался этим диском. Потом все-таки пригласили мастера, который и поведал, что диск он проверял сначала программой Victoria и она ничего сделать не смогла (?), потом поставил на MHDD для того, чтобы скрыть дефекты (???), но почему-то дефекты не скрылись... Вобщем подход с железной логикой - сначала скрыть все, что не читается, а потом смотреть, что получилось. Скажу сразу, что ничего хорошего в этом случае получиться не может и такой подход просто НЕ ДОПУСТИМ с точки зрения восстановления данных с неисправных накопителей. А если у HDD имеются еще и проблемы с записью (так, до кучи), то результат будет очень плачевным (об этом расскажу подробнее в одной из следующих статей).

Когда я заглянул в Grown-List этого накопителя - он был полон "под завязку" и скрывать дефекты уже было некуда (размер листа не резиновый :-). Туда наряду с дефектами, возникшими в процессе эксплуатации, соответственно были занесены и сектора, содержащие данные пользователя. Работа предстояла кропотливая. Сначала нужно было разобраться в том, какие сектора попали в дефект-лист "правильно", а какие "не правильно" и т.д.

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

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

]]> Sat, 04 Apr 2015 09:12:00 GMT https://www.itcvg.com/blog/?vosstanovlenie-informacii-s-nakopitelya-imeyushchego-bad-sektora https://www.itcvg.com/blog/rss/000000005