«Родила царица в ночь
Не то сына, не то дочь;
Не мышонка, не лягушку,
А неведому зверюшку»
A.С. Пушкин

Автомобильные блоки управления полны компонентов, промаркированных нестандартно. Например, встречались микросхемы, на которых выбито "Toyota", хотя ежу понятно, что Toyota никаких процессоров не производит. Но в мире электроники при больших партиях производители чипов имеют возможность выбить на чипе ваш логотип или маркировку, и разработчики ЭБУ этим активно пользуются, хотя цели их не совсем ясны.

Но нестандартная маркировка - это еще цветочки! Существует огромный пласт кастомных компонентов, выполненных "под заказ" для конкретного производителя ЭБУ. Такие проприетарные компоненты зачастую не только не имеют открытой документации, но и отсутствуют в линейке производителя.

Не так давно мы разбирались с процессором TMS470R1A256, очень популярным в блоках SRS 2007-2010 г.в.. На нём выбивают маркировки: TMS470R1VF3482 или TMS470AVF3482, однако достаточно подключиться к этому процессору посредством отладчика чтобы понять, что это процессор TMS470R1A256.

Дело в том, что согласно datasheet на эти процессоры, в каждом процессоре есть device identification code register, прочитав который, вы сможете узнать part number данного чипа, который уже можно отыскать в datasheet.
Например, для TMS470R1A256: `The assigned device-specific part number for the A256 device is 0001010` что при переводе в hex = 0x0A.

Много разработчиков написало "программы" для чтения ПЗУ данных процессоров, но почему-то блоки с процессорами, записанными этими "программами", не выходили на связь. Пришлось разбираться с этим вопросом самостоятельно, результатом чего стала версия программы JLinkZReader, в которой проблема чтения и записи данных CPU наконец-то была решена!

Неведомый процессор

Но встречается в ЭБУ и другая разновидность процессоров этого семейства, с маркировкой TMS470PV384 или TMS470PV249. И, как оказалось, этот процессор вообще не представлен в линейке производителя!

Первое, что бросается в глаза - это распиновка корпуса QFP-100. Если для TMS470R1A256 (далее для простоты будем называть ее TMS470R1) все совпадает с datasheet, то здесь мы находим такую распиновку только в процессорах TMS470MFx:

Однако серия TMS470MFx имеет ядро Cortex-M. Достаточно установить JTAG соединение с процессором чтобы увидеть #0 Id: 0x3100E02F, IRLen: 04, ARM7TDMI Core, из чего понятно что это ARM7TDMI, как у TMS470R1.

На этом странности не заканчиваются. Читаем Device ID Register:
0x8016210d (Бинарное: 10000000000101100010000100001101).

Видим, что младшие три бита составляют последовательность 101, что соответствует серии TMS470MFx, ибо у серии TMS470R1 первые три бита всегда 1. В зависимости от этого и расшифровывается регистр по-разному. Единственный обнаруженный нами процессор с архитектурой ARM7TDMI и содержащий эту последовательность был TMS470PLF111.

По его datasheet и произвели расшифровку идентификатора:
Ident Device: reg=0x8016210d, part=0xb, tech_family=0x1, silicon=0x1, rom_flash=0

Получили part number 0x0b. Казалось бы, осталось выяснить какой процессор семейства TMS470 имеет такой номер детали, но это не так-то просто. Действительно datasheet содержит этот пункт, но если набрать на сайте https://www.alldatasheet.com запрос по семейству TMS470 выпадает более 400 документов!

Поиск маркировки

Здесь на выручку пришла нейросеть, с помощью которой за полчаса удалось сделать довольно любопытный инструментарий. Фактически это скрипт на python, который:

• Формирует запрос по поиску документов на сайте https://www.alldatasheet.com;

• Скачивает каждый документ, обходя CAPTCHA и листая страницы;

• Делает паузы, чтобы не забанили за флуд;

• Переводит PDF в текстовый формат и находит нужные строки, содержащии PART NUMBER;

• Составляет финальную таблицу уникальных номеров деталей для всех имеющихся вариантов.

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

В результате данных изысканий был составлен полный список уникальных номеров деталей, которые можно получить из открытых документов по семейству процессоров TMS470 (правда тогда мы ещё не знали, что TMS470 это SM470... Но об этом чуть позже.

По данному коду детали был найден один процессор TMS470R1VC336, но вот незадача - в этом процессоре регистр Device Id имел такой же формат как в серии TMS470R1! Таким образом, получалось, что есть процессоры с таким part number, но datasheet говорит о них совсем не то, что мы видим. Есть процессор TMS470PLF111, но у него даже нет корпуса LQFP-100!

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

Сравнение и анализ

Как писалось ранее в другой статье, вычитывание ПЗУ этих процессоров не представляет очень большой сложности. Поэтому стоило как минимум считать программу, содержащуюся в процессоре блока SRS Fiat, и посмотреть к каким областям памяти она обращается.

Далее дадим исследуемому процессору аббревиатуру TMS470P для упрощения подачи материала.

Программа Fiat (TMS470R1):

Скрытый текст

Программа Fiat (TMS470P):

Скрытый текст

Что мы понимаем по сравнению этих фрагментов двух программ? Первое - мы имеем дело с процессором, очень похожим на TMS470R1, однако как минимум адреса регистров здесь отличаются.

Если обратиться к Memory Map из datasheet TMS470PLF111, то мы увидим следующее:

Для сравнения можно посмотреть в datasheet TMS470R1:

Скрытый текст

Как видно из приведённых фрагментов memory map, диапазон регистров работы с Flash в процессорах TMS470R1 имеет адреса 0xFFE88000-0xFFE8BFFF, в то время как у процессоров TMS470P он равен 0xFFF87000-0xFFF87FFF.

Казалось бы, можно попробовать отсчитывать регистры от нового BASE адреса, однако не всё так просто... Смещение регистра FMMSTAT в процессорах TMS470R1, например, 0x3C0C. Несложные вычисления показывают: 0xFFF87000+0x3c0c=0xfff8ac0c - выходим за пределы диапазона!

Что же делать? Как опознать смещения регистров и найти их для неведомого процессора TMS470P?

Для начала, используя JLink Commander, сделаем снимки памяти обоих процессоров в диапазонах флеш регистров. Теперь сравним их.

На смещении 0:

Скрытый текст

На смещении0x100 находим аналогию с 0x1c00 TMS470R1:

Скрытый текст

На смещении0x200 находим похожее в 0x2000 TMS470R1:

Скрытый текст

На смещении0x300 находим аналогию в 0x2800TMS470R1:

Скрытый текст

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

Находим заголовочные файлы ARM

Вспоминаем, что программы для семейства TMS470 писались с помощью ARM IAR Embedded Workbench. Поэтому устанавливаем этот продукт.

После того как пакет скачен и установлен, находим файлы заголовков, относящиеся к TMS470.

При рассмотрении файла FlashTMS470R1Axxx/f05a_api_src_027/f05.h было замечено, что существует некоторый define PLATFORM, который устанавливает различные оффсеты в двух конфигурациях. Очевидно, при установке TMS470R1 этот define не установлен, тут мы видим все известные нам адреса (деление на 4 связано с 32-битной адресацией):

#define BAC1               0x0000/4
#define BAC2               0x0004/4
#define BSEA               0x0008/4
#define BSEB               0x000c/4
#define DPTR               0x0010/4
#define REGOPT             0x1c00/4
#define MSTAT              0x3c0c/4

Для PLATFORM же видим следующее:

/* The PLATFORM flag can be specified in your cl470 CFLAGS as '-dPLATFORM'
 * or explicitly in a previous included header file using '#define PLATFORM'
 */
#ifdef PLATFORM
/* register offsets */
...
/* define aliases for PLATFORM */
#define REGOPT     FMREGOPT
#define BAC1       FMBAC1
#define BAC2       FMBAC2
...
#define MSTAT      FMMSTAT

#define FMREGOPT       0x0100/4
#define FMBAC1         0x0000/4 
#define FMBAC2         0x0004/4 
#define FMMSTAT        0x0024/4

И если BAC1, BAC2, DPTR совпадают, что и видно при сравнении дампов (записано магическое число 0x7F11), то далее видим аналогию 0x100 0x1c00, как показывало сравнение, приведённое ранее.

Таким образом, можно уверенно сказать, что процессоры серии P и есть PLATFORM!

Пишем загрузчик

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

1. декомпиляция готового загрузчика (например из пакета Segger JFlash или скомпилированных библиотек ARM IAR Embedded Workbench);

2. фрагменты примеров кода из документации [1];

Мы пошли по первому пути, так как для процессоров TMS470R1 прекрасно подходил загрузчик от SEGGER, однако с учётом того, что оптимизатор компилятора постарался, править его в ассемблере было чрезвычайно трудоёмкой задачей, поэтому мы решили перевести его в формат языка "Си", чтобы затем снова откомпилировать.

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

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

В какой-то момент, при стирании процессора мы получаем ошибку ACCESS DENIED. Как выяснилось, эта проблема относится к ключам безопасности уровня 2. Принцип работы этих ключей в данных процессорах очень интересный - можно свободно читать ПЗУ процессора, но нельзя стирать и записывать его, пока не укажешь правильные ключи. Сами ключи хранятся в определённой области флеш (которая для разных процессоров - разная!).

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

Но вот незадача, и IDA Pro, и нейросеть при анализе кода ассемблера загрузчика почему-то пропустили (соптимизировали) эту инструкцию. И здесь, внимание, включается полезный флаг декомпилятора Hex-Rays.

По умолчанию этот флаг снят, и программа установки доступа выглядела так:

Если же включить этот флажок, ситуация сразу меняется:

После устранения этих ошибок, процессор TMS470R1 действительно стал стираться, а вот TMS470P опять дал ошибку доступа! Почему же, спросите вы? А потому что мы не знаем, где именно хранятся ключи во флеш исследуемого процессора, и адрес, который мы читаем (а мы читаем адрес, специфицированный для TMS470R1) может быть совсем другим!

Согласно документации [5], ключи в процессорах хранятся в конце первого сектора:

Проблема в том, что для нашего процессора мы не знаем размер сектора! Узнать его очень просто - достаточно стереть сектор 0, и дальше перечитать память. Как только кончится стёртая область - вот он и конец сектора! Но чтобы стереть сектор, надо пройти авторизацию ключей. Замкнутый цикл! У TMS470R1 размер сектора был известен: 0x2000 байт. Раз этот вариант не сработал, пробуем 0x4000. И всё заработало!

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

Ссылки и документация

1. TMS470 Family – F05 Flash Module Software Peripheral Driver User’s Specification (SPNU257.pdf)

2. TMS470R1x Memory Security Module Reference Guide(SPNU243.pdf)

3. TMS470R1x F05 Flash Reference Guide](spnu213b.pdf)

4. TMS470R1x System Module Reference Guide](spnu189h.pdf)

5. Modifying the Flash Protection Keys of Catalog TMS470 Devices(spna094.pdf)

6. Atmel Corporation ARM7TDMITM Datasheet(arm7tdmi.pdf)

7. ARM7TDMI Technical Reference Manual(ARM7TDMI_technical_reference.pdf)

8. TMS470PLF111(TMS470PLF111PGEI.html.pdf)