|
Russian
Всем привет!
Занимаюсь исследованием CAM-модуля SMiT от Orange/бывшего Telekom. Пытаюсь получить расшифрованную прошивку, чтобы проанализировать её и разобраться в работе устройства.
Дамп внешней флеш-памяти уже снят, но его содержимое зашифровано. Подтверждённый незашифрованный исполняемый код пока получить не удалось.
Данные CAM-модуля:
- SoC: SMiT SM1670-N, определён по маркировке чипа.
- Внешняя RAM: ESMT M12L64164A-7T — SDRAM, 64 Мбит / 8 МиБ, 16-битная шина данных.
- Внешняя флеш-память: GigaDevice, при чтении определена как GD25Q127C; размер дампа — 16 МиБ.
- Модель, указанная в меню: SMiT_1670.
- Версия аппаратного обеспечения: 5.1.5.2.
- Приложение: 4.2.7.6 S, App-V28, сборка 2018-06-27 11:34.
- Verifier: 3.96.201.19, сборка 2018-07-26 13:57:04.
- Загрузчик: 1.2.0.0, L28, 0x042F.
- CAS ID, указанный в меню: 952, предположительно в шестнадцатеричном формате, то есть 0x0952. В сочетании с происхождением модуля от Telekom это указывает на NDS/VideoGuard.
Для сравнения имеются два дампа, снятые с двух CAM-модулей.
По имеющимся наблюдениям я сделал вывод, что UART отключён программно в прошивке. Документации, которая уточняла бы, действует ли это ограничение на всех этапах загрузки и существует ли отдельный заводской режим или режим восстановления, у меня нет. По полученной информации, прошивка также защищена цифровой подписью.
Таким образом, есть две отдельные задачи: получить код из зашифрованного образа и, если в дальнейшем вносить изменения, пройти проверку их подлинности. Сейчас моя цель — получить расшифрованную прошивку.
Проведённый анализ пока не позволил определить алгоритм и режим шифрования, ключ, карту памяти или подтверждённую точку входа. Точное процессорное ядро версии SM1670-N также не установлено.
Одно из возможных направлений — захват содержимого SDRAM во время работы, позволив самому CAM-модулю выполнить штатную расшифровку. Основной вопрос: расшифровывается ли прошивка с последующим копированием в ESMT или расшифровка происходит исключительно внутри SoC? Возможно также, что SDRAM содержит только рабочие данные, всё ещё зашифрованный код или сочетание разных компонентов.
Сейчас рассматриваю следующие варианты:
1. Захват обмена на шине SDRAM, если по ней передаются незашифрованные инструкции.
2. JTAG или другой отладочный/сервисный интерфейс, если он существует и доступен независимо от UART.
3. Диагностические функции через CI/PCMCIA, которые могли бы позволить чтение памяти.
4. Загрузчик, SDK/BSP или отладочная прошивка для близкой платформы SM1670-N/L28, которые помогли бы разобраться в загрузке и шифровании.
5. Поиск уязвимости в загрузчике или доступных интерфейсах, если остальные варианты не дадут доступа. На данный момент конкретной уязвимости не обнаружено.
Работал ли кто-нибудь непосредственно с этим поколением SMiT и может прояснить следующие вопросы?
- Выполняется ли прошивка из SDRAM или используется расшифровка при чтении внутри SoC?
- Применяется ли шифрование данных на шине SDRAM?
- Есть ли документация, распиновка отладочного интерфейса, сервисный режим или утилиты для этой версии?
- Удавалось ли кому-нибудь получить незашифрованный код из RAM или аналогичного дампа?
- Какое оборудование и какой подход были бы практически подходящими для захвата обмена на шине ESMT?
Предоставлю фотографии платы и маркировок, информацию из меню и результаты анализа. Особенно интересны практический опыт и документация именно по SM1670-N, поскольку сведения о других CAM-модулях SMiT не обязательно применимы к этой версии.
Спасибо!
English
Hi everyone,
I’m researching a SMiT CAM from Orange/former Telekom and trying to obtain the decrypted firmware to analyse it and understand how the device works.
I have already dumped the external flash, but its contents are encrypted. So far, I have not recovered any validated, unencrypted executable code.
The CAM details are:
- SoC: SMiT SM1670-N, identified from the chip markings.
- External RAM: ESMT M12L64164A-7T — 64 Mbit / 8 MiB SDRAM with a 16-bit data bus.
- External flash: GigaDevice, identified during readout as GD25Q127C; 16 MiB dump.
- Model displayed in the menu: SMiT_1670.
- Hardware version: 5.1.5.2.
- Application: 4.2.7.6 S, App-V28, build 2018-06-27 11:34.
- Verifier: 3.96.201.19, build 2018-07-26 13:57:04.
- Bootloader: 1.2.0.0, L28, 0x042F.
- CAS ID displayed: 952, presumably hexadecimal, meaning 0x0952. Together with the CAM’s Telekom origin, this points to NDS/VideoGuard.
I have two dumps from two CAMs available for comparison.
Based on the observations so far, I have inferred that UART is disabled by the firmware. I do not have documentation establishing whether this applies to every boot stage or whether a separate factory/recovery mode exists. According to information I have received, the firmware is also protected by a digital signature.
There are therefore two separate issues: recovering the code from the encrypted image and, if modifications are made later, having them accepted by the verification mechanism. My current goal is to obtain the decrypted firmware.
The analysis so far has not identified the encryption algorithm or mode, the key, a memory map, or a validated entry point. The exact CPU core used in the SM1670-N variant is also unconfirmed.
One possible approach would be capturing the SDRAM contents while the device is running, allowing the CAM to perform its normal decryption. The main unknown is whether the firmware is decrypted and copied into the ESMT SDRAM, or whether decryption happens entirely inside the SoC. The SDRAM could also contain only working data, code that remains encrypted, or a mixture of components.
The approaches I’m currently evaluating are:
1. Capturing SDRAM bus traffic, if unencrypted instructions cross that bus.
2. JTAG or another debug/service interface, if one exists and is accessible independently of UART.
3. Diagnostic functions exposed through CI/PCMCIA that might allow memory reads.
4. A bootloader, SDK/BSP, or development firmware closely related to SM1670-N/L28 that could help explain the boot process and encryption.
5. Investigating a vulnerability in the bootloader or existing interfaces if the other approaches do not provide access. No specific vulnerability has been identified so far.
Has anyone worked directly with this SMiT generation and can clarify the following?
- Does the firmware execute from SDRAM, or is it decrypted on the fly inside the SoC?
- Is encryption used to protect the SDRAM bus?
- Is any documentation, debug pinout, service mode, or tooling available for this variant?
- Has anyone successfully recovered unencrypted code from RAM or a similar dump?
- What equipment and approach would be practical for capturing traffic on the ESMT SDRAM bus?
I can provide board photographs, chip markings, menu information, and the analysis results. I’m particularly interested in practical experience or documentation for SM1670-N, since information about other SMiT CAMs may not apply to this variant.
Thanks!
Скачать файл можно после регистрации регистрация | вход
|
testupc