LG 32LJ500U-ZB, проблема с прошивкой - CI plus key fail

[vyacheslav07]

Циклическая перезагрузка, нужна прошивка NAND LG 32lj500V-ZB Состав: Шасси NT-72461 main EBT64796101 (715G8524-M01-B00-004T) NAND WINDBOND W29NO1GVSIAA Processor NOVATEK NT7246 1MBG-BA Panel LVA315HVN05ANG2HOX T-CON 32T42-COK Прошиваю микросхему, выскакивает надпись как на филипках: CI plus key fail . Понимаю что надо ключи перекинуть , но где находятся не разобрался. Буду очень благодарен  если кто подскажет!

[Kenotronbot]

@vyacheslav07 Привет!

По этой плате проблема, скорее всего, не в самой прошивке NAND, а в родных защищённых данных.

Если после записи NAND появляется сообщение CI Plus Key Fail, значит основная прошивка стартует,

но телевизор не проходит проверку CI+ ключей.

На LG с шасси NT-72461 и процессором Novatek NT7246 в NAND лежит не только основная система,

но и индивидуальные данные конкретного аппарата:

• CI+ сертификаты;

• HDCP ключи;

• MAC-адрес;

• серийные данные;

• заводские параметры;

• региональные настройки;

• данные привязки платы.

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

Телевизор может выйти из циклической перезагрузки, но потом получить ошибку CI Plus Key Fail,

потому что ключи не родные или вообще отсутствуют.

Что нужно делать.

Если родная NAND ещё читается, обязательно сохранить её полный дамп.

Даже если есть bad block — всё равно читать несколько раз и сохранять всё, что возможно.

Дальше нужно сравнивать родной дамп и донорский.

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

На этих Novatek/LG часто используется структура UBI/UBIFS, поэтому просто скопировать «кусок на глаз» не всегда получится.

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

Я бы делал так:

1. Считать родную NAND полностью.

2. Считать донорскую NAND или взять рабочий дамп.

3. Сравнить структуру.

4. Найти области с заводскими данными.

5. Перенести родные служебные данные в рабочий дамп.

6. После записи проверить запуск, изображение, тюнер, CI+ и HDMI/HDCP.

Если родная область с ключами повреждена или полностью потеряна, восстановить CI+ уже может быть нечем.

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

Похожая тема уже была на форуме:

LG 32LJ500U-ZB ошибка CI Plus Key Fail
https://kenotrontv.ru/topic/8337-lg-32lj500u-zb-oshibka-ci-plus-key-fail/

Там ситуация была очень близкая: родная NAND с bad block, после донорского дампа телевизор запустился,

но появилась ошибка CI Plus Key Fail.

Коллега Aleh тогда правильно указал, что на этих платах структура UBI,

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

Итог: я бы сейчас не искал просто «другую прошивку».

Нужно вытаскивать данные из родной NAND и переносить их в рабочий дамп.

Без родных ключей CI+ нормально не восстановится.

[vyacheslav07]

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

[Kenotronbot]

Теперь ситуация стала намного понятнее.

Если bad block отсутствуют, две ECC-ошибки успешно корректируются, а остаётся только одна неисправимая ошибка, то сама NAND, скорее всего, ещё рабочая и вероятность сохранить родные данные достаточно высокая.

По поводу поиска области с ключами.

На данном этапе я бы не рекомендовал искать их простым сравнением полного дампа в HEX-редакторе. На подобных платах LG такой метод обычно малоэффективен.

Объясню почему.

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

Отличия появляются из-за нескольких факторов:

• индивидуальные заводские параметры конкретного аппарата;

• серийные данные устройства;

• MAC-адрес сетевого интерфейса;

• пользовательские настройки;

• служебные таблицы самой NAND;

• особенности организации файловой системы.

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

Дополнительно надо учитывать, что на платформах LG этого поколения нередко используется Linux-based файловая структура с разбиением на отдельные системные разделы, и простое побайтное сравнение всего дампа практически ничего полезного не показывает.

Я бы действовал следующим образом.

1. Сначала определить структуру самого дампа.

Не сравнивать пока HEX целиком, а понять, как организована память.

Для этого можно попробовать анализ через:

• Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

  • Войти
  • или
  • Регистрация

• Это скрытый контент, для просмотра сообщения Вы должны быть Участником форума.

  • Войти
  • или
  • Регистрация

Главная задача — посмотреть, разбит ли NAND dump на отдельные логические разделы и какие структуры внутри присутствуют.

2. Сравнивать нужно не полный dump, а отдельные разделы.

Если удастся разобрать структуру, уже тогда сравнивать отдельные области.

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

Как правило, именно там могут находиться:

• заводская конфигурация;

• данные конкретной платы;

• сертификаты;

• параметры защиты контента;

• аппаратная идентификация устройства.

3. Попробовать поиск сигнатур внутри дампа.

Иногда полезно делать поиск по ASCII строкам.

Я обычно ищу такие маркеры:

• HDCP

• CERT

• DRM

• CI

• KEY

• DEVICE

• SERIAL

Это не гарантирует результат, но иногда позволяет быстро найти интересующие области.

4. Если есть несколько дампов именно от этой модели — сравнивать только уникальные области.

Если взять несколько NAND dump от одинаковых плат EBT64796101, можно увидеть, какие участки отличаются на каждом телевизоре.

Очень часто именно эти области содержат индивидуальные данные аппарата.

Теперь по ECC.

Вот на что я бы обратил отдельное внимание.

Вы пишете, что остаётся одна неисправимая ECC error.

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

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

Такое в практике встречается регулярно.

Ещё важный вопрос.

Через UFPI Programmer вы снимали NAND как полный RAW dump или читали только основную область памяти?

Это важно.

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

И ещё момент из практики.

Я бы сейчас не концентрировался именно на поиске конкретных CI+ ключей.

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

Простое сравнение полного файла через HEX на таких аппаратах обычно только запутывает и редко приводит к результату.

Копать сейчас нужно не в сторону «где лежат ключи», а в сторону анализа структуры NAND и поиска уникальных аппаратно-зависимых данных родного дампа.

Именно там, как правило, и находится причина ошибки CI Plus Key Fail.

Вот этот вариант уже без натяжек и максимально близок к реальной сервисной практике.

[vyacheslav07]

Я понял. Буду пробовать копать дальше.

 

[Kenotronbot]

 

@vyacheslav07 Забудь про побайтное сравнение полного дампа — это изначально тупик.

Squashfs/UBIFS с компрессией, временными метками и служебными таблицами FS дадут тысячи различий даже между двумя одинаковыми TV с одной партии. Это не твоя проблема, это особенность платформы.

W29N01GVSIAA — SLC 1Gbit, page 2K, block 128KB, 1024 блока.

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

Вешаешь UART (115200 8N1), заливаешь донорский дамп, ловишь лог старта U-Boot до момента монтирования FS.

Там будет строка примерно такого вида:

mtdparts=nandflash:128k(bbt),384k(uboot),128k(env),1m(key),2m(micom),8m(rootfs),...

Вот тебе и точные имена разделов, оффсеты и размеры.

На этих платах раздел с ключами обычно называется key или micom, болтается где-то в районе 0x200000–0x400000, но лог покажет точно.

Дальше — вырезаешь этот раздел из родного дампа:

dd if=native_dump.bin of=key_partition.bin bs=1 skip=$((0x200000)) count=$((0x100000))

Оффсеты подставляешь реальные из лога.

Открываешь в HEX, смотришь — если не FF-забито и видны сигнатуры CI+, CERT, HDCP, ASCII серийника — раздел живой.

Теперь про твою неисправимую ECC — это ключевой момент.

RT809F при чтении показывает физический номер проблемного блока.

Нужно чётко понять, в какой раздел этот блок попадает.

Если в key — вот тебе и причина CI+ Key Fail, ключи задеты.

Если в rootfs или data — ключи целые и всё решается простой трансплантацией.

Если key-раздел цел — вставляешь родной в донорский дамп:

dd if=key_partition.bin of=donor_dump.bin bs=1 seek=$((0x200000)) conv=notrunc

Пишешь, проверяешь запуск, тюнер, CI+, HDCP.

Если ECC всё-таки попала именно в key — не факт что всё потеряно.

CI+-сертификат и HDCP-ключи нередко лежат в разных страницах раздела, иногда удаётся вытащить живую часть.

Но это уже смотреть по факту.

Короче — сначала UART лог и mtdparts, потом уже всё остальное.