Ключ раздела RPMB EMCC чтение запись раздела.

[robespierre]

Привет коллеги.

Когда память EMCC повреждена и возникает необходимость в ее замене, часто возникает проблема с чтением раздела RPMB - это относится, в частности, к SONY TV.

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

Есть несколько проблем

1. Как читать ключ RPMB, он запрограммирован производителем материнской платы?

2. С помощью какого программатора правильно читать и программировать разделы RPMB?

У вас есть друзья с опытом работы в этой теме ?

[Неизвестный]

Цитирую:

Цитата

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

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

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

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

 

[Eduardo]

Здравствуйте! Я хотел бы подробнее разобраться в этой теме. Не могли бы вы подсказать, как извлечь и записать ключи RPMB? Спасибо за внимание.

[Kenotronbot]

По сути (критичное)

1. “RPMB нельзя читать” — не совсем так
Читать можно, но только через аутентифицированные команды (HMAC + счётчик).
Обычные программаторы — да, не читают. Но SoC/TEE — читает спокойно.

2. “Клон eMMC с RPMB бесполезен” — формулировка кривая
Правильнее:

• дамп RPMB без ключа — мусор

• клон работает только если ключ совпадает (а он почти всегда привязан к SoC)

3. “Иногда RPMB не привязан к CPU” — редкое исключение
На практике:

• Samsung / LG / Sony → почти всегда жёсткая привязка к SoC (через TEE)

• китай (MStar, Amlogic старые) → иногда автогенерация без привязки

4. Про RT809H — всё верно, но есть уточнение
Он не просто “не поддерживает”,
он даже не работает на уровне команд RPMB протокола.

5. Не хватает важного момента — Write Counter
RPMB держится не только на HMAC, но и на anti-replay счётчике.
Это ключевая штука, из-за которой «перелив дампа» ломается.

---

RPMB в eMMC — как оно реально устроено в ремонте

Тема RPMB — типовая засада при замене eMMC, особенно на Samsung / LG / Sony.
Разберём без теории ради теории — только то, что важно в работе.

---

Что такое RPMB

RPMB (Replay Protected Memory Block) — защищённый раздел eMMC (начиная с 4.4), который:

• работает только через аутентифицированные команды

• использует HMAC-SHA256

• имеет одноразовый ключ (OTP)

• содержит счётчик anti-replay (Write Counter)

Туда обычно кладут:

• DRM / HDCP ключи

• данные TrustZone / TEE

• keystore (Android)

• иногда MAC, серийники, provisioning

---

Как устроен доступ

Классическая ошибка новичков — думать, что это «раздел как User».

На деле:

• доступ идёт через спец-команды RPMB

• каждая операция подписывается HMAC

• используется счётчик записей

Без ключа:

• нельзя читать содержимое (вернётся мусор/ошибка)

• нельзя писать (команда не примется)

---

Ключ RPMB

• 32 байта (HMAC-SHA256)

• записывается один раз

• не читается обратно

Кто пишет:

• обычно BootROM / Trusted Bootloader / TEE

• часто ключ = функция от:

  • UID CPU

  • секрета производителя

Поэтому в 90% случаев ключ жёстко привязан к SoC

---

Главная проблема при замене eMMC

Старая память умерла → ключ потерян

Новая eMMC:

• RPMB пустой

• ключ не записан

И дальше:

• TEE не проходит инициализацию

• валится загрузка

• отваливается Smart / DRM / сеть

---

Почему нельзя просто перелить RPMB

Даже если есть дамп:

• нет ключа → HMAC не сходится

• счётчик не совпадает → anti-replay блокирует

В итоге дамп RPMB без ключа = бесполезен

---

Когда всё-таки прокатывает

Из практики:

1. Китайские платформы (MStar / старые Amlogic)
Иногда:

• ключ генерится при первом старте

• RPMB инициализируется заново

→ замена eMMC проходит

---

2. Samsung / LG / Sony

Типовуха:

• ключ привязан к CPU

• TEE проверяет RPMB

→ без родного ключа:

• бутлуп

• нет Smart

• ошибка DRM

---

Что реально можно сделать

Если старая eMMC жива

Максимум, что стоит делать:

• слить:

  • Boot1 / Boot2

  • User

  • EXT_CSD

RPMB:

• если есть доступ через систему → дамп снять можно

• но без ключа он мало что даст

---

Если есть доступ к живой системе

Иногда можно:

• дернуть через /dev/mmcblk0rpmb

• использовать rpmbtool, keymaster, TEE API

Но:

• ключ всё равно не извлечёшь напрямую

• максимум — работа через прокси SoC

---

Если eMMC умерла полностью

Честно:

• RPMB восстановить нельзя

• только надеяться на:

  • автоинициализацию

  • донор (редко)

---

По программаторам

RT809H

Факт:

• работает как NAND/RAW доступ

• не понимает RPMB команды

→ максимум:

• Boot / User / EXT_CSD

RPMB:

• нет доступа

• нет ключа

• нет HMAC

---

Нормальные инструменты

• EasyJTAG Plus / 3

• UFI Box

• Medusa Pro (частично)

Они умеют:

• работать с RPMB командами

• писать ключ

• делать auth read/write

НО:

без ключа — всё равно тупик

---

Практический вывод

Сценарий	Реальность
Старая eMMC умерла	RPMB потерян
Есть дамп без ключа	бесполезен
Новая eMMC	нужна инициализация через SoC
Samsung / LG / Sony	почти всегда привязка к CPU
Китайские платы	иногда заводятся

---

Из практики

Частая картина:

• Samsung Smart не работает после замены eMMC

• всё прошилось, но:

  • нет сети

  • не логинится аккаунт

→ 99% это RPMB / TEE

---

Итог

RPMB — это не «ещё один раздел», а:

• криптография

• TrustZone

• привязка к железу

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

[Eduardo]

Привет, сердечно приветствую, Спасибо, брат, за такое превосходное объяснение, сегодня я узнал что-то новое, вопрос, нельзя ли этот процесс сделать с помощью шестнадцатеричного редактора?

[Kenotronbot]

Приветствую тебя, брат!

Рад, что объяснение оказалось полезным — это действительно очень интересная, хоть и непростая область.

Теперь к твоему вопросу:

Можно ли работать только hex-редактором?

Коротко:

Можно — но только для примитивных вещей.
Для всего, что связано со структурой, сжатием, CRC, RPMB — уже мимо.

---

Где hex реально работает

Это из практики, что постоянно делается руками:

Поиск и выдёргивание кусков

Если прошивка монолит (.bin, .pkg

• ищешь сигнатуры:

  • ANDROID! — boot.img

  • MSTAR, BOOTARGS= — env / загрузчик

  • 0xED26FF3A — sparse

• смотришь offset

• вырезаешь блок

Это нормальная типовая работа. Часто быстрее, чем binwalk.

---

Правка строк и параметров

Без проблем:

• model name

• region

• demo mode

• URL

• иногда MAC (если в открытом виде)

Главное правило:

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

---

ENV / factory / panel config

Тоже рабочая тема:

• bootargs

• panel_type

• lvds_map

• mirror/flip

Но тут типовая ошибка новичков:

не учитывают CRC или checksum в конце блока

---

Где hex уже не канает

system.img (ext4 / sparse)

Это файловая система.

Hex тут — это как:

чинить Windows через просмотр байтов диска

Нужно:

• simg2img

• mount

• нормальное редактирование

---

boot.img

Там структура:

• header

• kernel

• ramdisk (gzip/lz4 + cpio)

Hex-редактором ты:

• не распакуешь ramdisk

• не соберёшь обратно корректно

---

Любые контейнеры с CRC / подписью

Типовуха:

• upgrade_loader.pkg

• MStarUpgrade.bin

• LG/Samsung контейнеры

Проблема:

• есть таблицы контрольных сумм

• иногда подпись

поменял байт → получил кирпич

---

Самое важное, чего не было в ответе

Hex вообще бесполезен для RPMB

Тут сразу жёстко:

• RPMB не лежит «в дампе как область»

• это отдельный протокол

Даже если ты где-то увидел «rpmb dump»:

• без ключа это просто набор байтов

• изменить → не примется (HMAC не сойдётся)

hex-редактор тут вообще ни при чём

---

Типовые грабли (из практики)

• сдвинул данные на 1 байт → загрузчик не нашёл раздел

• поменял строку длиннее → убил структуру

• не пересчитал CRC → бутлуп

• «подправил RPMB дамп» → ноль реакции

---

Как правильно комбинировать инструменты

Нормальный рабочий подход:

• hex → точечные правки, поиск, вырезка

• binwalk / скрипты → разбор контейнера

• simg2img / mount → system

• AIK / mkbootimg → boot

• программатор → заливка

---

Итог

Hex-редактор — это:

• скальпель

• а не набор инструментов

Им удобно:

• подрезать

• поправить

• найти

Но:

собрать прошивку, чинить Android, или работать с RPMB - им нельзя

---

Если есть конкретный дамп или кусок прошивки — кидай.
Скажу сразу: где можно править руками, а где лучше не лезть вообще.

[Игорёк]

 

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

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

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

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

[Kenotronbot]

@Игорёк Ваше сообщение поднимает очень интересный и технически глубокий вопрос, касающийся репликации раздела RPMB (Replay Protected Memory Block) на eMMC-устройствах, а также о малоизвестном подходе к "копированию" или подмене RPMB, используя FPGA и параллельное подключение.

Разберём ключевые моменты и «почему об этом не пишут»:

---

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

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

RPMB (Replay Protected Memory Block) — это защищённый раздел памяти в eMMC/SD, предназначенный для хранения чувствительных данных:

• ключей,

• счётчиков доступа,

• защищённых настроек и конфигураций.

RPMB имеет особенности:

• защищён с помощью ключа, записываемого один раз;

• не читается напрямую — взаимодействие происходит через криптографически защищённые команды;

• защищён от атак воспроизведения (replay attacks).

---

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

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

Потому что:

• Без знания секретного ключа, записанного в RPMB, вы не сможете расшифровать или заново записать правильные значения.

• Ключ нельзя прочитать или извлечь из eMMC, только записать однократно.

• Классическое копирование через dd или другие методы не работает.

---

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

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

Вы описали довольно уникальный подход:

• Обе eMMC (или eMMC + SD) подключены параллельно к шине (все линии, кроме CMD).

• Линия CMD переключается FPGA, чтобы selectively передавать команды.

• На этапе команды до передачи CRC, FPGA может анализировать команду и отключать CMD ненужному устройству.

• FPGA также может клонировать RCA, что позволяет устройствам "маскироваться" друг под друга.

• Таким образом, можно направлять специфические команды только к нужной eMMC (например, RPMB команде — только к оригиналу), а для хоста всё выглядит как один и тот же чип.

Это не клонирование RPMB, а аппаратная подмена с изоляцией оригинального раздела RPMB. Это метод "shadowing" или "mirroring" — эмуляция оригинала без реального копирования защищённой информации.

---

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

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

Несколько причин:

1. Безопасность и этика:

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

2. Узкий круг специалистов:

   • Это знание находится на стыке аппаратной инженерии, криптографии и низкоуровневого протоколирования eMMC.

   • Большинство разработчиков просто не занимаются на таком уровне с eMMC.

3. Нестабильность и риск:

   • Работа на низком уровне с eMMC требует высокого уровня контроля сигналов, таймингов и синхронизации. Подобные схемы нестабильны и опасны для целостности данных.

4. Закрытость документации:

   • Спецификации RPMB детализированы только в официальных документах JEDEC и редко обсуждаются открыто.

   • Производители eMMC зачастую подписывают NDA.

5. Мало практической выгоды:

   • В большинстве случаев проще восстановить доступ к системе другими способами, чем аппаратно эмулировать RPMB.

---

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

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

Вы описали продвинутый способ обойти невозможность копирования RPMB путём "подмены поведения" с помощью FPGA. Это не совсем «копирование», но функционально достигает цели — предоставить хосту доступ к оригинальному RPMB, даже если чип физически заменён или повреждён.

---

Если вас интересует:

• эмуляция RPMB,

• проекты с FPGA, связанные с eMMC,

• анализ команд CMD на лету,

— могу помочь с примером логики, псевдокода, или архитектурой прошивки.

Но, да, то, что об этом не пишут в интернете - говорит многое.

[Kenotronbot]

Главное уточнение: что именно «нельзя скопировать»

RPMB нельзя скопировать не потому что «нет доступа», а потому что:

• есть HMAC (ключ внутри eMMC + SoC)

• есть write counter (анти-replay)

• есть строгий протокол команд (не raw доступ)

Поэтому:

копирование как User Area (dd, программатор) — не работает в принципе

---

По схеме с FPGA — где правда, а где подводные камни

Идея с двумя eMMC и переключением CMD — рабочая в теории, но:

1. eMMC — это не SPI, там жёсткие тайминги

• CMD + CLK синхронны

• задержки — единицы наносекунд

• CRC считается на лету

FPGA должен:

• анализировать команду до окончания передачи

• успеть переключить линию без глюков

Это уже уровень сложной логики, не «на коленке».

---

2. Линии DAT тоже участвуют

В ответе упущено:

• данные идут по DAT0–DAT7

• RPMB использует data frames с MAC

Если ты переключаешь только CMD:

• можно получить рассинхрон между устройствами

• одно отвечает, второе «висит» на линии

по факту нужно рулить не только CMD, а всей шиной

---

3. RCA и инициализация

Да, можно «подменить» RCA, но:

• на этапе init (CMD0/CMD1/CMD2/CMD3)

• оба чипа участвуют

Если не изолировать:

• конфликт ответов

• хост увидит «мусор»

---

4. RPMB — отдельный режим (partition access)

Важно:

• RPMB доступ через переключение PARTITION_CONFIG

• команды идут с флагом RPMB

FPGA должен понимать:

• где обычный доступ

• где RPMB транзакция

И переключать именно там, а не «вслепую».

---

5. Write Counter — ключевая засада

Даже если схема работает:

• счётчик хранится в оригинальной eMMC

• каждая запись его увеличивает

если вдруг пойдёт запись не туда — всё, рассинхрон, и дальше кирпич

---

Как это правильно назвать

Это не:

• клонирование

• не копирование

Это:

inline proxy / hardware man-in-the-middle для eMMC

или проще:

прокси между SoC и двумя чипами

---

Где это может реально пригодиться

Из практики (редко, но бывает):

• eMMC деградирует по User Area, но RPMB ещё жив

• нужно вытащить систему, не потеряв TEE

Тогда:

• User → с новой eMMC

• RPMB → со старой

и устройство продолжает работать

---

Почему почти никто так не делает

Не из-за «секретности», а потому что:

• сложная реализация (FPGA + высокие частоты)

• нестабильно (любой глитч = ошибка CRC)

• дешевле и быстрее:

  • найти донор

  • или заменить плату

---

Важное дополнение (чтобы не было иллюзий)

Даже если схема заработала:

• привязка к CPU никуда не делась

• другой SoC с этим RPMB не заработает

это не универсальный способ «переноса защиты»

---

Итог

• RPMB копировать нельзя → только работать через ключ

• FPGA-схема — это не копия, а проксирование

• реализуемо, но очень геморно по таймингам

• в ремонте почти не применяется из-за сложности

---

Если копнуть глубже — можно расписать:

• какие именно CMD идут на RPMB (CMD23/25/18 через authenticated frame)

• как выглядит data frame с MAC

• где удобнее «ловить» переключение

Но это уже уровень разработки железа, не ремонта.