Pull to refresh
164
0
Янчарский Павел @hddmasters

специалист по восстановлению данных

Send message

Даже если снять дамп с флешки — там же хитрые алгоритмы выравнивания износа и коррекции ошибок, и тоже разные для разных контроллеров — данные так просто не восстановить.

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

Многие флешки и вовсе не требуют изучения структур FTL (flast translator layer), а достаточно служебных данных в блоке или странице, чтобы можно было определить положение в логическом пространстве реализуемом накопителем.

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

А вы тоже все реверсите с нуля, или какая-то информация по контроллерам все же доставаемая?

с нуля.

А почему в данном случае использовался только картридер, заказчик был против потрошения карты?

Карта в монолитном исполнении (контроллер+память в одном керамическом корпусе). Карта выходит в готовность и трансляции работает. Особого смысла читать NAND в котором слишком много битовых ошибок не имеет большого смысла. Кроме дополнительных осложнений при анализе монолита здесь скорее всего ничего бы не получили.

По моему небольшому опыту — подавляющее большинство проблем что с SD что с USB флешками носит чисто софтовый характер — видимо слетает прошивка или какие-то таблицы контроллера.

Основная масса проблем:
1. износ NAND памяти и неустойчивое чтение или нечитаемость структур FTL
2. повреждение структур FTL

Также довелось поэкспериментировать с factory командами одной USB флешки — там помимо прочего была возможность читать/писать данные в сыром виде — для мелочи типа SD карт такой спосом имхо гораздо безопаснее потрошения

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

Способ прочитать NAND микросхему средствами комплексов PC3000Flash или Flash Extractor выглядит более надежным, чем чтение микросхем средствами микропрограммы носителя, которая не гарантирует выдачи корректного содержимого из страниц памяти.

Да и как вообще добраться до памяти micro SD без риска угробить ее окончательно — не очень понятно.

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

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

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

Экономической целесообразности в реанимации карт памяти не видится, поэтому вряд ли нами будет исследоваться этот вопрос.

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

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

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

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

Мы не изучали этот вопрос. Такой задачи не стояло. Восстановленное ПО записывалось на другую MMC карту Siemens и стартовало.

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

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

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

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

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

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

Изначально мы выяснили, что PLC универсальны сами по себе и одинакового ПО ждать не стоит если нет 100% клона конвейера.

в сегодняшних условиях, когда Siemens может отказаться(или уже отказался) от поддержки своих продуктах возможно масштабирование приведённого в статье процесса...

Siemens в этом случае лишь производитель универсальных PLC. Программное обеспечение - это разработка третьей стороны.

А какие есть более надежные носители информации? Вечных не бывает.

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

Мне видится, что в текущей ситуации - сами виноваты, что бекапов не было.

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

А если серьезно, такие решения - дичь полная, с точки зрения надежности.

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

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

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

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

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

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

 Такое встречается в смартфонах, планшетах, телевизорах и прочей технике.

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

Например еще можно отдельно отметить мультимедийные системы автомобилей. Например в случае Tesla из-за выхода из строя копеечной микросхемы eMMC в случае официального сервиса придется раскошелиться на новую систему за 1500-3000$, при цене микросхемы заметно меньше 1% от всей мультимедийной системы. Будь там флеш-карта или сменный SSD, то скорее всего был бы отверточный ремонт с прошивкой за куда более скромные деньги.

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

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

К счастью в случае исправных MMC карт от Siemens Simatic S7-300 не возникает никаких проблем с созданием корректного файла-образа. К примеру WihHex или любое ПО, умеющее поблочно (посекторно) читать накопитель, справится с этой задачей.

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

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

Возможно при наличии свободного времени напишу очередную публикацию, где рассмотрю часть алгоритмов работы микропрограммы какого-либо относительно простого SSD.
Не забывайте про различные USB коробочки, которые вносят свою лепту. И при таком раскладе устройств, где для ОС сектор более 512 байт становится значительно больше.

А так да, в случае различных 2,5" SATA накопителей очень мало устройств у которых нет эмуляции 512 байт в секторе.
поправка:
А MBR не покрывает более 1Tb диска.


классическая таблица разделов содержит в себе величины DWORD для описания смещений и длин разделов в секторах. 32 бита без знака позволяют описать от 0 до 4 294 967 295 секторов

При размере сектора 512 байт — это будет ровненько 2ТБ
беря в расчет менее привычные случаи, например сектор 4096 байт, получим поддерживаемую емкость в 16ТБ.
С самой вычиткой проблем не будет. Обычная процедура локализации крупных дефектообразований и многопроходное чтение до получения максимально возможного результата. Под результатом подразумевается посекторная копия.

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

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

читать как «кабальные договоры»
Но считывать информацию лазером можно-я специально лазил после прочтения по терминам запомнил «Магнитооптический эффект Керра»


Как бы это попроще сказать…

В теории якобы можно.

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

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

А потом писать эмулятор каждого семейства жестких дисков, которому можно будет скормить полученные «оцифрованные пластины». (посмотрите в сторону MFM, RLL дисков, где хватает описаний работы сервосистемы и поймете сколько вспомогательных данных на пластинах. А потом добавьте всю эволюцию кодирования данных в магнитной записи, чтобы понимать всю сложность такого эмулятора и заодно учтете, как из рисунков придется выделять все эти вспомогательные «данные» для эмулятора)

Боюсь, что при современных технологиях и ожидаемых затратах — это в принципе пока что нереализуемо. А говорить о каких-то чтениях предыдущих состояний и вовсе не приходится.
смотрите официальный источник, который указан в конце предыдущего комментария. Там же написано, что именно делал Kroll Ontrack, а не чьи-то пространные рассуждения.
1
23 ...

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity