Как стереть nand память

Обновлено: 02.07.2024

Deex, добивайся запуска кселла. а то ещё стоит пролить ритэйл и отпаять чип - возможно аппаратные проблемы.

Изменено JamalShooter: 11.04.2015 - 14:57

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

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

Лично я считаю так: Разбирай консоль, цепляй флешер и считывай нанд. Распаковывай нанд. Если есть KV_dec, FCRT_dec, SMC и SMC_Config то всё отлично, можно собрать даже ритейл с возможность использовать привод. Для уверенности скачай чистые SMC (Google в помощь). Смотри фьюзы и при сборке ставь нужное LDV. Если всётаки дамп будет битый, то собирай из донора с чистым SMC и галкой NOFCRT. Но в данном случае про ритейл можешь забыть, только фрибут.

P.S. Если в чём-то заблуждаюсь поправьте.

Как собрать донорский нанд?как потом его закинуть на консоль если уменя она просто выбивает ошибку е71,ксел включается только через ноут.

Как собрать донорский нанд?как потом его закинуть на консоль если уменя она просто выбивает ошибку е71,ксел включается только через ноут.

1. Выдержка из моей памятки- "Собирать будем при помощи программы J-Runner. Что для этого нужно?

1.Программа J-Runner.
2.CPU KEY вашей приставки.
3.Nand донора(от приставки с идентичными показателями).
4.Флешер(для записи).?
5.CDридер(для записи в Corona 4gb).
Открываем программу.В поле Source File вставляем нанд донора.

Жмем Tools,затем Extract Files.

Программа извлечет нужные для сборки файлы.Извлеченные файлы будут находиться в папке J-Runner>output.

Теперь жмем Restart(для перезапуска программы).
Открываем папку J-Runner>output.Для создания Retail-Glitch Nand нам понадобятся следующие файлы:

1. fcrt_dec-если был извлечен(переименовать в fcrt)
2.KV_dec-(переименовать в KV)
3.smc_config-(не переименовывать)
4.smc.bin файл(чистый)скачать архив с чистыми smc можно тут.
Находим в архиве файл для своей приставки(например Corona)и переименовываем его в smc.Копируем переименованные файлы в папку J-Runner>xebuild>data

В программе J-Runner в поле CPU KEY вставляем свой ключ и выбираем тип Retail либо Glitch2
Далее в Advanced жмем Create an image without nanddump.bin появится окошко с выбором числа LDV(ставим значение из фьюзов)и жмем ОК.
Появится окно Type (выбираем тип своей приставки)и жмем ОК.

Программа начнет сборку(процесс сборки можно увидеть в логе)."

2. я же тебе написал. "цепляй флешер"

3. Тоесть как это кселл включается через ноут.

Изменено Spirit62: 14.04.2015 - 09:32

Уменя corona 4g, кселл на екран не выводиться,только при подключение через лан к ноуту,а без флешера и пайкы можна ето сделать?Потому как купить флешер нету возможности.

Уменя corona 4g, кселл на екран не выводиться,только при подключение через лан к ноуту,а без флешера и пайкы можна ето сделать?Потому как купить флешер нету возможности.

собирай SD reader

Ребят помогите восстановить утерянный нанд(((

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

Здравствуйте потерян оригинальный nand , что нужно чтобы собрать другой ? помогите пожалуйста ключи у меня есть

Накопители на основе флэш-памяти с каждым днем принимают все более изощренные и миниатюрные формы, что повышает их мобильность до запредельной. Сегодня большинство электронных устройств, неспособных к перемещению в пространстве, теряют как минимум привлекательность среди основной массы потребителей, и, как максимум, возможность оказаться в нужном месте в нужное время. Такая мобильность иногда чревата последствиями. Вспомним и сравним, как часто мы теряли HDD-диски и насколько чаще теряем флэшки. Что касается производителей, то они оценили преимущества флэш-памяти и успешно используют ее во многих мобильных устройствах. В числе наиболее востребованных на рынке — накопители на основе NAND флэш-памяти. Область их применения постоянно растет: от мобильных телефонов до маршрутизаторов. Такая популярность делает актуальным вопрос сохранности и безопасности информации с устройств такого типа. Именно это и стало поводом для детального рассмотрения основных принципов и особенностей восстановления информации с накопителей на основе NAND флэш-памяти.

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

По статистике нашего центра восстановления данных, доля случаев обращения пользователей с флеш-накопителями в процентном соотношении непрерывно растет, и в июне 2009 года сравнялась с количеством случаев для IDE HDD. Из 100% случаев восстановления, на IDE HDD и флэш-накопители приходится по 20%. На сегодняшний день, наибольший объем работ по восстановлению данных мы производим на SATA-накопителях. В то же время по нашим прогнозам, примерно через год количество случаев с FLASH-накопителями существенно потеснит случаи восстановления данных с SATA.

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

Почему ломаются накопители, или немного теории

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

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

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

Итак, вернемся к логическим повреждениям.

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

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

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

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

Есть вероятность успешного возобновления работы накопителя при замене МС контроллера на заведомо рабочий, полностью совпадающий или «похожий», но эта вероятность крайне мала. Даже относительно одинаковые контроллеры отличаются по применяемым алгоритмам распределения данных и алгоритмам ECC, в результате чего при замене возможны ситуации несовместимости. При этом работоспособность накопителя не восстановится, но новый контроллер, обнаружив несоответствие формата данных на микросхемах памяти, вероятно, переформатирует ее «под себя», уничтожив пользовательские данные. Хотя иногда подобная практика и имеет успех.

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

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

Восстановление данных в деталях

Итак, как мы уже сказали, наиболее частые причины повреждения флэш-накопителей любого типа — это проблемы электрического и теплового характера. Статическое электричество, некорректное подключение питания USB-разъемов на панели системного блока и другие проблемы с питанием становятся причинами сгорания контроллера накопителя. Это, естественно, делает невозможным любой доступ к содержимому микросхем флэшки. Если помехи питания кратковременны или незначительны, тогда маловероятно, что сам контроллер выйдет из строя, но и он может поспособствовать сбою при модификации данных на микросхемах памяти. В результате, нарушается логика работы механизма трансляции— по внешним признакам это эквивалентно повреждению контроллера. Учитывая, что контроллер оперирует блоками данных минимальным размером около 128К байт, такой кратковременный сбой может привести к полному стиранию основных структур файловой системы. Это, очевидно, сделает невозможным дальнейшее функционирование накопителя.

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

Все это с успехом аккумулировано в программно-аппаратном комплексе PC-3000 Flash, естественно, за исключением процедуры выпаивания микросхем памяти.

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

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

AlcorMicro
SK
SM
ChipsBank
iCreate
Lexar
USBest
PHISON
OTI
SSS
TOSHIBA

Описание работы по восстановлению информации было бы неполным без статистики, собранной и обработанной с декабря 2007 года. Около 80 процентов данных с флэш-накопителей NAND удается восстановить в автоматическом режиме, то есть с помощью одного щелчка мышью. При детальном «ручном» восстановлении — 90 процентов данных обретают вторую жизнь. Сразу оговоримся, что оставшиеся 10 процентов информации тоже возможно спасти. Для этого потребуется время и сочетание технологий автоматического и механического восстановления.

Интересна и статистика восстановления данных при различных типах повреждений. От общего объема восстановления информации на накопителях на основе NAND флэш-памяти 45% приходится на устранение неисправностей логического характера, соответственно, 55% — физического.

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

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

Механизмы шифрования и защиты данных файловой системы iOS теперь хорошо документированы и поддерживаются многими утилитами ПТЭ (программно-технической экспертизы или forensics). В качестве основной области хранения данных iOS-устройства используют NAND flash-память, но создание физических образов обычно имеет отношение к "dd image" логических разделов. Уровень трансляции Flash в iOS для текущих устройств имеет программную основу (реализован в iBoot и ядре), что означает, что CPU имеет прямой доступ к сырой NAND-памяти. В данном посте мы опишем, как получить образ NAND и использовать FTL-метаданные для восстановления удаленных файлов на устройствах, использующих процессор A4. Информация, представленная здесь, основана на серьезной работе по реверс-инжинирингу, выполненной командой iDroid/openiBoot.

Чтение NAND-памяти

iOS-устройства используют один или несколько идентичных чипов, адресуемых номером CE ("chip enable"). Фактические параметры геометрии (число CE, число блоков на CE, число страниц на блок, размер страниц и резервной области) зависят от модели устройства и общей емкости хранилища. Физический адрес составляется из CE-номера чипа и физического номера страницы (PPN) на этом чипе.

Из-за ограничений NAND в операционных системах распространены механизмы трансляции (FTL), которые позволяют использовать NAND-память как обычное блочное устройство, оптимизируя при этом ее производительность и срок службы. Главная цель FTL заключается в уменьшении операций стирания и распределения их по всем блокам. С точки зрения ПТЭ, интересным побочным эффектом здесь является то, что при перезаписи логического блока на уровне блочного устройства старые данные на физическом уровне обычно не стираются сразу. Поэтому при поиске удаленных данных работа с сырым образом NAND может быть очень полезна.

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

Начиная с iOS 3 на ram-дисках Apple iOS можно найти программу ioflashstoragetool. Данная утилита может производить множество низкоуровневых операций, касающихся flash-хранилища и может читать сырые NAND-страницы и резервные области (не производя никакого рода дешифрования). Данная функциональность предоставлялась сервисом ядра IOFlashControllerUserClient.

В iOS 5 большая часть функций, предоставлявшихся данным интерфейсом IOKit, была убрана. Чтобы создать дамп посредством этого интерфейса, мы можем загрузить ram-диск с помощью более старой, четвертой версии ядра iOS. Это отлично работает, однако в таком случае мы потеряем способность использовать имеющийся код ядра для атаки перебором более новых связок ключей iOS 5. Чтобы выгрузить NAND под пятой версией ядра iOS, мы заново реализовали часть функции IOFlashControllerUserClient::externalMethod, ответственной за функциональность чтения. Когда наш инструмент выгрузки запускается под пятой версией ядра iOS, он замещает данную функцию той, что обрабатывает селектор kIOFlashControllerReadPage.

Кроме того, мы можем установить флаг загрузки nand-disable-driver, чтобы предотвратить высокоуровневый доступ к NAND и гарантировать, что ее содержимое не изменится в ходе получения.

Уровень преобразования Flash в iOS

Уровень преобразования Flash (FTL), используемый в iOS, основан на Samsung Whimory FTL (WMR). Команда openiBoot проделала хорошую работу по его реверс-инжинирингу, так что мы можем понять используемые в нем структуры и механизмы. Код преобразования Whimory делится на два слоя: VFL и FTL.

Virtual Flash Layer (VFL) ответственен за переназначение bad-блоков и представление NAND, не содержащее ошибок, для FTL-слоя. VFL-слой знает физическую геометрию и транслирует виртуальные номера страниц, используемые FTL, в физические адреса (номер CE + номер физической страницы).

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

В различных версиях iOS использовались следующие варианты подсистем FTL:

iOS 1.x и 2.x : "legacy" FTL/VFL
iOS >= 3 : YaFTL / VSVFL
Начиная с iOS 4.1, некоторые из новых устройств оснащены PPN (Perfect Page New) NAND, которая использует особый PPNFTL.

PPN-устройства имеют свой собственный контроллер с прошивкой, которая может быть изменена через интерфейс IOFlashControllerUserClient, но большая часть работы FTL похоже все еще выполняется программно – с помощью YaFTL поверх нового PPNVFL.

На основании кода openiBoot мы написали минимальную read-only реализацию YaFTL/VSVFL на Питоне, чтобы получить возможность просматривать образы NAND как блочные устройства. В сочетании с реализацией HFS+ на Питоне она позволяет извлечение логических разделов для получения эквивалента dd-image. Далее нам нужно понять механизмы YaFTL, чтобы воспользоваться дополнительными данными, доступными в образе NAND.

YaFTL

Следующий рисунок обобщает процесс преобразования YaFTL:

В ходе нормальной работы в каждый момент лишь один суперблок каждого типа является "открытым": страницы записываются последовательно в манере log-block. Когда текущий суперблок заполнен, YaFTL находит пустой суперблок для продолжения процесса. старевшие пользовательские данные стираются только в процессе работы сборщика мусора.

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

Восстановление FTL производится при загрузке, если FTL не был должным образом отмонтирован (после kernel panic или жесткой перезагрузки, например) и контекстная информация не была зафиксирована на flash-носителе. Функции восстановления FTL приходится исследовать все блоки (используя BTOC для ускорения процесса), чтобы восстановить корректный контекст.

Метаданные резервной области

iOS резервирует 12 байт каждой страницы в резервной области для хранения метаданных. Формат метаданных YaFTL описан в openiBoot:

Поле lpn позволяет FTL-коду проверять корректность преобразования при чтении страницы. Оно также используется в ходе процесса восстановления FTL, чтобы обнаруживать страницы в "открытых" суперблоках, которые не имеют BTOC.

В поле usn записывается глобальный порядковый номер обновления во время записи страницы. Этот номер увеличивается каждый раз при фиксации новой версии контекста FTL или когда суперблок заполнен и происходит открытие нового суперблока. Данное поле позволяет легко сортировать суперблоки по возрасту.

"Отбеливание" метаданных

Аппаратное шифрование применяется только к действительным данным страницы, т. е. не применяется к резервной области. На недавно появившихся устройствах с iOS 4 метаданные хранятся в резервной области и скремблируются в ходе процесса, называемого "отбеливанием метаданных". 12 байт структуры Sparedata подвергаются побитовому исключающему или (XOR) с псевдослучайными значениями, зависящими от физического номера страницы. Данный алгоритм можно найти в openiBoot: static uint32_t h2fmi_hash_table[256]; . void h2fmi_init() < .
// This is a very simple PRNG with
// a preset seed. What are you // up to Apple? -- Ricky26
// Same as in 3GS NAND -- Bluerise uint32_t val = 0x50F4546A; for(i = 0; i < 256; i++)
< val = (0x19660D * val) + 0x3C6EF35F; int j; for(j = 1; j < 763; j++) < val = (0x19660D * val) + 0x3C6EF35F; >
h2fmi_hash_table[i] = val; > . > error_t h2fmi_read_single_page(. ) < . if
(h2fmi_data_whitening_enabled) < uint32_t i; for(i = 0; i < 3; i++) ((uint32_t*)_meta_ptr)[i] ^=
h2fmi_hash_table[(i + _page) % ARRAY_SIZE(h2fmi_hash_table)]; > . >

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

Восстановление удаленных файлов

Считать каждую резервную область в образе, чтобы найти страницы с типом PAGETYPE_LBN, и прочитать поле lpn (метод грубой силы)
Пробежать каждый непустой пользовательский суперблок, прочитать BTOC, где это возможно, или просканировать все страницы, если блок не полный

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

Перечислить все идентификаторы файла на разделе данных в его текущем состоянии: мы используем обычную трансляцию FTL и EMF-ключ для расшифровки данных.
Получить местоположение текущего файла каталога и файла аттрибутов (диапазоны LBA)

Для каждого LBA, принадлежащего файлу каталога

Для каждой версии текущего LBA

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

Пробежать в цикле все возможные ключи шифрования и версии первого логического блока, пока расшифрованное содержимое не совпадет с магическим числом (обычная магия файловых заголовков). См. функцию isDecryptedCorrectly (которую можно улучшить).
если найдены ключ шифрования и USN первого блока, считать следующие блоки файлов, используя данный USN как ссылку. Другой метод – начать считывать страницы, начиная с первого найденного блока файлов, следуя "порядку записи" FTL: читать до конца суперблока, затем продолжить в следующем с более высоким значением USN, и так, пока не будут найдены все блоки файла.

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

Один из файлов, который было бы интересно восстановить – системное хранилище ключей. Если атакующий смог получить доступ к первой версии системного хранилища ключей (без установленного пароля, сразу после восстановления прошивки), он мог бы затем получить доступ ко всем ключам классов без необходимости в атаке пароля пользователя. Однако, эксплуатировать более старые версии хранилища ключей невозможно из-за второго слоя шифрования: полезная нагрузка systembag.kb шифруется ключом BAG1, который хранится в уничтожаемой области и принимает случайное значение каждый раз, когда на диск записывается новая версия файла (когда пользователь меняет свой пароль). Данный механизм, очевидно, был разработан для предотвращения подобных атак, как объяснено в выступлении "Securing application data" с Apple WWDC 2010 (Сессия 209).

Уязвимость стирания в iOS 3.x

Теперь, имея возможность читать сырое содержимое NAND, мы еще раз взглянем на механизмы iOS 3. В то время весь раздел данных (включая содержимое файлов) был зашифрован ключом EMF, который хранился (зашифрованным) в последнем логическом блоке раздела. Поскольку в это время не было уничтожаемой области, мы полагали, что данный последний логический блок управлялся FTL, как и остальная часть раздела. Путем получения NAND-образа сразу после стирания устройства под управлением iOS 3 становится возможно найти две версии данного логического блока: одну с новым EMF-ключом, сгенерированным в ходе стирания и одну, которая была перезаписана только на уровне блочного устройства. Таким образом, используя старый ключ и собрав старые страницы раздела данных (на основании USN операции стирания), возможно (частично) восстановить стертый раздел данных. Конечно, эта уязвимость исправлена в iOS 4 с помощью уничтожаемой области, которая позволяет ключам шифрования безопасно стираться.

Инструменты получения содержимого NAND и вырезания данных теперь доступны в репозитории iphone-dataprotection. Дополнительные подробности также доступны на вики. Наконец, большое спасибо Патрику Вилдту и команде openiBoot за их работу над iOS FTL, которая позволила нам создать эти инструменты.

Я думаю некоторые жертвы кирпичей, услышали от мастеров следующее: Память мертвая, вы или замените материнку, или новый смартфон приобретайте. Но, я решил копаться в недрах смартфонов Xiaomi и получить то чего, практически НИКОМУ нельзя использовать даже в Официальных Сервис Центрах Xiaomi, а темболее рядовому пользователю. А именно возможность восстановления битых Flash накопителей. И так, я получил специальное ПО для восстановления Flash накопителей, и специальные программаторы для этого.

Конечно, спросите а как восстанавливаю битый Flash Накопитель ?

Процесс:

•Изначально разбирается смартфон на кусочках.
•Далее, извлекаю Flash накопитель с посадочного места на материнке смартфона через Инфракрасный специальный сеппаратор (Благодарю Alkris2 за ссылку на сие аппарат).
•Подготовится накопитель к восстановлению и посадочное место на материнской платы.
•Накопитель ставится в специальный программатор и заливается прошивка чипа через так называемый Экстренный режим прошивки чипа, не материнки.
•Заливается Сама прошивка смартфона (Благо чип ожил).
•Припается чип обратно на своё посадочное место на материнке.
•Проверяется работоспособность смартфона.
•Если смартфон оживит, собираем и отдаем владельцу, если не оживит, заново повторяем процесс.

Конечно, я думаю, даже сам Админ захочет получить данную Инфу. Но, повторюсь, я НЕ ИМЕЮ ПРАВО дать даже ему такую информацию. Откуда я получил такую инфу ? Тоже молчу. секрет. Это всего лишь была краткое описание по восстановлению кирпичей с битым Flash накопителем. И как описал выше, не дал ничего. Даже на фото не имею право показать, даже готовое устройство. Так как производитель не дает ни в коем случай доступ к такой информации. Но я получил её через моих специальных путей. И к сожалению восстановление чипа (по удаленке) для других Mi Фанов не буду делать, так что не ждите. Повторюсь, штраф мне не по карману, за это меня могут даже посадить в тюрьму. А также, восстановление кирпичей в целом не смогу помочь, из за того что идет слежка за аккаунтом, каждая прошивка регистрируется на серверах Xiaomi. А вы знаете что Китай строго следит за своей продукцией, причем ооочень строго.

В декабрьской версии тритоновской программы (V5.8.56), добавлена возможность проверки и коррекции ошибок при работе с микросхемами NAND-FLash. Учитывая, что данная тема очень сложная, и не многие программаторы поддерживают эту функцию в полном объеме, вопросов может быть немало. Чтобы понять тематику вопросов и не объяснять каждому одно и то же, на основные вопросы я отвечу здесь.

Что сделано (версия V5.8.56).
- На данный момент программа поддерживает основные алгоритмы коррекции ошибок: Хемминга, Рида-Соломона, БЧХ.
- В режиме Автокоррекции программа распознает 50 различных конфигураций этих алгоритмов.
- Программа позволяет исправлять считываемые из микросхемы данные и очищать чужой файл от ошибок при записи микросхемы.
- Проверено около 80 разных микросхем и более 200 дампов от LCD телевизоров, спутниковых ресиверов, принтеров, DVD, DVR, GPS, WIFI.
- Из имеющегося архива программа определяет около 80% алгоритмов ECC.

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

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

Или другой пример, запись многострадальной K9GAG08U0E. В большинстве случаев, без проверки ECC, программатор покажет, что все нормально. Но с учетом того, что в файле есть 21 страница с некорректируемыми ошибками, работа телевизора будет под вопросом.3 раза перечитал "Так и не понял кто на ком стоял" (c).
Что предлагается обсуждать?
Обход bad-блоков как правило осуществляется в устройстве процессором программно. Простые железки в работе после загрузки никакие ecc/crc не используют, и в бут процедурах проверяют целостность некоторых частей или всего флеша. И если все гут то все работает а если нет, то фиксируется наличие проблемы с вытекающими последствиями - незапуском или косяками в работе, как разработчик наразрабатывал. Ecc/crc и признак bad-блока пишется только при записи во флешь. И каким алгоритмом считаются контрольные суммы зависит опять же от разработчика. Если при записи на программаторе изменить алгоритм расчета сумм то в устройство не заработает. И все богатство выбора алгоритмов нужно для максимального покрытия существующих решений.
Если после записи флеша фиксируются ошибки в страницах которые не входят в bad-блок то следует пометить соответствующий блок признаком bad и переписать флешь заново с последующим контролем. Но если вся прошивка не войдет во флешь из-за уменьшения его размера флешь придется менять.
Сам писал софт для работы с нанд, разбора прошивки, сборки дампа, расчета контрольных сумм, обхода bad-блоков. Ничего сложного в этом нет.
Или другой пример, запись многострадальной K9GAG08U0E. В большинстве случаев, без проверки ECC, программатор покажет, что все нормально. Но с учетом того, что в файле есть 21 страница с некорректируемыми ошибками, работа телевизора будет под вопросом.
Это как? Содержимое страницы совпадает с дампом а ECC не сходится? Вывод простой - если данные верны а ECC кривое, то проблема не в странице с данными а в ECC.

Информация Неисправность Прошивки Схемы Справочники Маркировка Корпуса Сокращения и аббревиатуры Частые вопросы Полезные ссылки

Справочная информация

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

Диагностика
Определение неисправности
Выбор метода ремонта
Поиск запчастей
Устранение дефекта
Настройка

Неисправности

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

не включается
не корректно работает какой-то узел (блок)
периодически (иногда) что-то происходит

О прошивках

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

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

Схемы аппаратуры

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

Справочники

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

Marking (маркировка) - обозначение на электронных компонентах

Современная элементная база стремится к миниатюрным размерам. Места на корпусе для нанесения маркировки не хватает. Поэтому, производители их маркируют СМД-кодами.

Package (корпус) - вид корпуса электронного компонента

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

DIP (Dual In Package) – корпус с двухрядным расположением контактов для монтажа в отверстия
SOT-89 - пластковый корпус для поверхностного монтажа
SOT-23 - миниатюрный пластиковый корпус для поверхностного монтажа
TO-220 - тип корпуса для монтажа (пайки) в отверстия
SOP (SOIC, SO) - миниатюрные корпуса для поверхностного монтажа (SMD)
TSOP (Thin Small Outline Package) – тонкий корпус с уменьшенным расстоянием между выводами
BGA (Ball Grid Array) - корпус для монтажа выводов на шарики из припоя

Краткие сокращения

При подаче информации, на форуме принято использование сокращений и аббревиатур, например:

Сокращение	Краткое описание
LED	Light Emitting Diode - Светодиод (Светоизлучающий диод)
MOSFET	Metal Oxide Semiconductor Field Effect Transistor - Полевой транзистор с МОП структурой затвора
EEPROM	Electrically Erasable Programmable Read-Only Memory - Электрически стираемая память
eMMC	embedded Multimedia Memory Card - Встроенная мультимедийная карта памяти
LCD	Liquid Crystal Display - Жидкокристаллический дисплей (экран)
SCL	Serial Clock - Шина интерфейса I2C для передачи тактового сигнала
SDA	Serial Data - Шина интерфейса I2C для обмена данными
ICSP	In-Circuit Serial Programming – Протокол для внутрисхемного последовательного программирования
IIC, I2C	Inter-Integrated Circuit - Двухпроводный интерфейс обмена данными между микросхемами
PCB	Printed Circuit Board - Печатная плата
PWM	Pulse Width Modulation - Широтно-импульсная модуляция
SPI	Serial Peripheral Interface Protocol - Протокол последовательного периферийного интерфейса
USB	Universal Serial Bus - Универсальная последовательная шина
DMA	Direct Memory Access - Модуль для считывания и записи RAM без задействования процессора
AC	Alternating Current - Переменный ток
DC	Direct Current - Постоянный ток
FM	Frequency Modulation - Частотная модуляция (ЧМ)
AFC	Automatic Frequency Control - Автоматическое управление частотой

Частые вопросы

Как мне дополнить свой вопрос по теме Коррекция ошибок в NAND-FLash?

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

Кто отвечает в форуме на вопросы ?

Ответ в тему Коррекция ошибок в NAND-FLash как и все другие советы публикуются всем сообществом. Большинство участников это профессиональные мастера по ремонту и специалисты в области электроники.

Как найти нужную информацию по форуму ?

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

По каким еще маркам можно спросить ?

По любым. Наиболее частые ответы по популярным брэндам - LG, Samsung, Philips, Toshiba, Sony, Panasonic, Xiaomi, Sharp, JVC, DEXP, TCL, Hisense, и многие другие в том числе китайские модели.

Какие еще файлы я смогу здесь скачать ?

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

Полезные ссылки

Здесь просто полезные ссылки для мастеров. Ссылки периодически обновляемые, в зависимости от востребованности тем.

Читайте также: