Как-то раз получил задачу - "взломать" протокол передачи данных внутри торгового автомата. Торговый автомат по продаже охлаждённых газированных напитков, включает несколько цифровых плат, объединенных сетью RS-485 - судя по наличию чипов MAX485 на платах.
Заказчик хотел заменить старую плату индикации режима работы на Raspberry Pi, при этом протокола передачи данных у него не было и схем тоже. Сам заказчик и его громоздкое оборудование находилось очень далеко от нас, и чтобы не тратить лишнее время и деньги, предложили сфотографировать цифровые платы и купить дешевый китайский логический анализатор.
Cовместимый с программой Saleae Logic - очень удобная программа для такого взлома. На фото плат, сделанных заказчиком, нарисовали, куда подключиться на индикаторной плате, а именно на вход передатчика и выход приемника чипа MAX485 - чтобы видеть, что приходит на плату индикации и что она отправляет в ответ - если вообще отправляет.
Затем вместе удаленно, через Teamviewer, сделали записи потоков данных в различных режимах. Внимание! Teamviewer уже бесполезен, события давно происходили.
Примеры режимов в терминах платы индикации - всё исправно, идёт охлаждение сиропа, сироп закончился, общая неисправность, требуется обслуживание, и т.п. Всё это для двух независимых контейнеров с разным сиропом. На плате индикации все возможные состояния отображались 6-ю светодиодами.
В итоге получили более 16 файлов в формате Saleae Logic 1.x с записями во всех режимах, которые смог обеспечить заказчик на своем оборудовании. В программе сразу было видно, что скорость примерно 38925 бод ( ближайшая стандарная 38400 ). Все остальные параметры передачи байта - 8 бит, 1 стоповый бит, без бита четности и т.п.
Программа Logic 1.x может показывать сразу расшифрованные байты, если задать параметры протокола передачи байта. По паузам получилось выделить отдельные сообщения. В итоге, после просмотра записи, получили представление о том, когда и какие байты передаются в различных ситуациях. Например, каждое сообщение начинается с байта 0xC0 и заканчивается байтом 0xC1:
Пауза 3с после включения
Байты принимаемые платой индикации: 0xC0, 0x01, 0x7D, 0xE0, 0x01, 0x40, 0xF7, 0xFA, 0xC1
Пауза 0.25мс
Байты принимаемые платой индикации: 0xC0, 0x01, 0x40, 0x01, 0x7D, 0xE0, 0xF6, 0x0A, 0x03, 0x01, 0x55, 0xC1
Пауза ~95 мс
Байты, принимаемые платой индикации: 0xC0, 0x02, 0x00, 0x01, 0x40, 0xF7, 0x8D, 0xC1,
0xC0, 0x01, 0x40, 0x02, 0x00, 0xF6, 0x28, 0x03, 0x00, 0xAB, 0xC1,
Пауза ~95 мс
Байты, принимаемые платой индикации: 0xC0, 0x02, 0x00, 0x01, 0x40, 0x13, 0x02, 0x83, 0xC1, 0xC0, 0x01, 0x40, 0x02, 0x00, 0x12, 0x02, 0x02, 0x02, 0x01, 0x01, 0x27, 0xC1,
Пауза 94 мс
Байты, принимаемые платой индикации: 0xC0, 0x01, 0x80, 0x01, 0x40, 0xF7, 0x1A, 0xC1,
0xC0, 0x01, 0x40, 0x01, 0x80, 0xF6, 0x20, 0x03, 0x04, 0x7D, 0x5D, 0xC1,
Пауза 95 мс
Байты, принимаемые платой индикации: 0xC0, 0x01, 0x80, 0x01, 0x40, 0x17, 0x02, 0x01, 0x00, 0x28, 0x60, 0x32, 0x00, 0x28, 0x60, 0x32, 0x00, 0x1D, 0x4C, 0x32, 0x00, 0x1D, 0x4C, 0x32, 0xF6 0xC1,
0xC0, 0x01, 0x40, 0x01, 0x80, 0x16, 0x20, 0xC1,
Пауза 1186 мс
Байты, принимаемые платой индикации: 0xC0, 0x01, 0x80, 0x01, 0x40, 0x15, 0x00, 0x00, 0x00, 0x00, 0x7A, 0xC1,
0xC0, 0x01, 0x40, 0x01, 0x80, 0x14, 0x00, 0x35, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x64, 0x00, 0x00, 0x64, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x8E, 0xC1
Пауза 49 мс
Байты, принимаемые платой индикации: 0xC0, 0x02, 0x00, 0x01, 0x40, 0x11, 0xB9, 0xC1
Пауза 9.3 мс
Байты, принимаемые платой индикации: 0xC0, 0x01, 0x40, 0x02, 0x00, 0x10, 0x00, 0xFA, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0xC1-
Пауза 33.3 мс
Байты, принимаемые платой индикации: 0xC0, 0x01, 0x7D, 0xE0, 0x01, 0x40, 0x23, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00, 0x8E, 0xC1
#-------- в этом сообщении есть байты, меняющиеся в зависимости от состояния устройства
Пауза 0.23 мс
Байты, передаваемые платой индикации: 0xC0, 0x01, 0x40, 0x01, 0x7D, 0xE0, 0x22, 0x64, 0xC1 После изучения всех 16-ти записей стало ясно, что данные о состоянии устройства есть в сообщении, начинающимся с байтов 0xC0, 0x01, 0x7D, и после этого сообщения сразу следует сообщение от платы индикации.
Информации стало достаточно, чтобы заменить плату индикации на одноплатный миникомпьютер Raspberry Pi с адаптером RS-485.
На своей стороне собрали имитатор передаваемых сообщений с выходом RS-485, добавили в него записанные сообщения. Подключили к своей Raspberry Pi через адаптер, написали и отладили простую программу на Python с выводом в консоль принимемых сообщений.
Заказчик закупил всё необходимое, отключил плату индикации и подключил Raspberry Pi через адаптер RS-485, согласно нашей схеме подключения. Предоставил нам удалённый доступ по SSH к подключенному Raspberry Pi. После подачи питания на устройство раздался возмущённый писк из торгового автомата, по документации - сигнализация о поломке.
Не обращая на писк внимания, запустили нашу программу. Писк исчез. Как выяснилось позднее, отсутствие быстрого ответа в виде сообщения от платы индикации воспринимается основной платой как поломка.
Данные о состоянии оборудования принимались правильно и стабильно.
Писк оказался проблемой. После включения питания торговый автомат немного пищал, пока запускалась программа на Raspberry. Иногда неожиданно автомат мог пискнуть, правда, это происходило крайне редко и не каждый день. Как выяснилось, время ожидания ответа менее 300мкс. Сначала переписали программу приема данных на Си и запустили её отдельным процессом, потом разработали свою плату адаптера RS-485 Raspberry Pi с микроконтроллером, единственной задачей микроконтроллера было разпознавать запрос и оперативно на него отвечать. После этого писк после подачи питания исчез, так как микроконтроллер запускается почти мгновенно по сравнению со временем загрузки ОС в Raspberry Pi.
Первая версия серийного адаптера с микроконтроллером:
Следующим этапом стало добавление функций в программу на Raspberry Pi, а именно запуск большого рекламного видео на мониторе, отображение
аварийных состояний иконками справа и слева, отправка телеметрии на web сервер.
Торговый автомат после всех доработок, с монитором и Raspberry Pi внутри. Работает моя программа. Желтые иконки внизу показывают, что сироп закончился:
Далее разрабатывали почти заново сайт Заказчику, добавляли удаленную загрузку видео с этого сайта на торговый автомат, писали ему кучу самых разных программ и многое-многое другое. Но это уже совсем другая история.
Комментарии (15)
RZK333
01.09.2022 02:40+2>дешевый китайский логический анализатор
это пиратский клон реально существующего анализатора от Saleae, оригинал стоит от $500, то что у вас - втыкать в важные устройства немного опасно. тоже самое можно сказать о софте который с ним идёт.
ruomserg
01.09.2022 06:12+6И какие именно опасности? При условии, что перед вводом в эксплуатацию китайский анализатор вскрыт, осмотрен на предмет замыкакний/болтающихся кусков припоя и отмыт от остатков флюса? Уж не хотите ли вы сказать что в оригинальном — входа гальванически развязаны ?! В общем, хотелось бы подкрепления данного заявления описанием отличий по схемотехнике…
raspberry_pi_soft Автор
01.09.2022 07:22+1У Заказчика в итоге сгорел сам анализатор, и не один. Подозреваю, что он на горячую куда-то подключал. У меня ни разу не сгорал, часто пользовался, особенно при отладке программ для микроконтроллеров. Но они очень дешевые и легко купить. Программу скачивали с официального сайта Saleae Logic.
nsk_artem
01.09.2022 11:33+3Поддерживаю, у самого есть отладка на CY7C68013A, использовал её с Saleale Logiс, но как-то не зашло, в итоге перешел на PulseView (sigrok) - ничуть не хуже.
Также был опыт использования Kingst LA1010 (сейчас стоит 3.4кР, ранее стоил примерно 2кР), с их софтом - у него больше частота дискретизации, до 100МГц, и 16 полноценных каналов. Софт родной китайский в целом нормальный, но иногда вис намертво при подключении анализатора или запуске анализа, так и не понял, в чем дело.
В целом, для большинства проектов вполне хватает и самого простого анализатора, очень сильно выручал много раз.
Например, была задача отреверсить протокол подключения датчиков и моторов к детскому конструктору WeDo 2, чтобы непрофессионалу можно было удобно проверять большое количество периферии, просто подключая её к разъему, и тыкая кнопочку (среди периферии есть датчик наклона на гироскопе, датчик расстояния на ИК-датчике отражения и мотор, надо было наглядно показывать, что работает ОК). Протокол там простецкий, на базе UART, просто меняется часть данных в посылке - можно было даже USB-UART + терминалом отреверсить, но проще и безопаснее сначала проверить, что там точно UART, а не I2C, например.
К сожалению, дальше прототипа дело не пошло, ковид усилился, денег в компании стало мало, проект (а потом и весь инженерный отдел) заморозили:(
Примерно так это должно было выглядеть - недоделанная плата.
raspberry_pi_soft Автор
01.09.2022 12:10Выглядит очень хорошо. И информация по 100МГц полезная, спасибо, иногда 24МГц не хватает, а 100МГц обычно дороже стоят. По нашим разработкам ковид тоже ударил, заказчиков несколько месяцев почти не было, был только заказ для отображения панорамы гидролокатора корейского. Потом хоть заказчики опять появились, например разрабатывали сеть очистителей воздуха на Raspberry Pi с управлением в том числе со смартфона, настройки таймеров озонатора и УФ ламп и т.п. Можно сказать, интернет вещей. Протоколы MQTT, сервер, сайт и т.д. :
Устройства - это очистители воздуха, для ковида востребованы были, особенно год и два назад. Надолго работы хватило. Хотя технические решения были простые.
nsk_artem
01.09.2022 18:02+1Спасибо!
По поводу ЛА - насколько я помню, он не может выдавать эти 100МГц при использовании всех каналов, а только при использовании двух или трех из всех. Если использовать все каналы, ЧД падает до 16 МГц или около того, надо смотреть описание. На практике не приходилось доходить до таких частот, поэтому не могу точно сказать, насколько правда. Но один неоспоримый плюс есть - в комплекте просто великолепный USB-A->USB-B кабель, очень гибкий и мягкий, не утягивает ЛА за собой. Брали, кстати, анализатор в оф. магазине на Алике.
Про очистители воздуха - да, в родном городе (Новосибирск) есть компания, которая занимается производством умных бризеров и подобного, несмотря на их цены, покупатели у них есть, а во время ковида стало ещё больше.
А у вас прямо полноценный промышленный интернет вещей выходит, судя по схеме. Если не секрет, как реализовали OTA-обновление на таком масштабе? Отдельным приложением на одноплатнике? При таком количестве устройств без OTA любой баг это ужас просто.
Кстати, не рассматривали ли OrangePi как альтернативу Raspberry? Был с ними опыт работы, в целом, прикольная штука, но конечно, и комьюнити меньше, и доков иногда совсем нет, но цена намного ниже, а версии, которым уже лет 5+ (OrangePi PC) вполне стабильно работают.
raspberry_pi_soft Автор
01.09.2022 18:44+1Для обновления программ ( ОТА ) организовали SSH туннель к каждой Pi. С Orange Pi мы сталкивались по двум работам, например этой весной с Orange Pi C4. Заказ был по портированию программы с GUI с Raspberry. Включая видеоплеер. Что не понравилось - под полноценную Linux c X server нет видеодрайверов, графические приложения работают очень медленно. Есть видеодрайвер под версию только с консолью. Существующие видеоплееры все с нюансами, ни один под нашу задачу не подошел. Железо в Orange Pi отличное, но c поддержкой производителем драйверами проблема. Мои личные впечатления. Всё с Orange решаемо, но долго и мучительно.
ITMatika
01.09.2022 12:13Круто! Но это только проверка имеющейся периферии? Новые дополнительные модули, наверное, сложно будет подружить с контроллером и родным софтом типа WeDo 2.0 LEGO® Education.
И ещё, может знаете живые сообщества по WeDo/Boost/Spike?nsk_artem
02.09.2022 00:47+1Да, это только проверка.
На самом деле чаще всего ломаются моторы, из огромной горы моторов и датчиков (думаю, штук по 80+ было датчиков, а моторов больше сотни, докупали запасные), датчиков поломанных было всего пара-тройка, а вот моторов десятка четыре, практически везде проблемы с кабелем, так как дети как только нвд ними не издеваются:( причем многие моторы были далеко не первый раз на починке.
Чтобы можно было кому угодно поручить проверку моторов, изначально сделал несколько простых тестеров, тупо H-мост на двух парах N+P мосфетов, AO4606, кажется, на скрине выше они в SO-8 корпусе. Управление там обычным слайдером, завтра попробую найти фотку или плату.
Этого в принципе хватало, но потом возникла идея сделать более навороченное устройство для внутренних нужд организации. Легально его продавать вряд ли бы вышло, это для EV3 есть и схемы, и SDK, а для WeDo ничего нет, все закрыто и проприетарно, но пользы было бы много. Ну и дальше случилось то, что случилось, собственно.
Я разбирал дохлые модули и датчики, в датчиках стояли stm8, тогда еще дешманские, а вот насчет блока я не помню, кажется, там стоял EFM32, но могу путать, если надо, могу поискать фото платы, может быть остались.
Как я и говорил выше, никаких доков и SDK найти не удалось, но возможно, если попросить вендора, то он поделится.
Можно попробовать закостылить датчик, сэмулировав один из тех, что в наборе, то есть отправлять свои данные, которые блок будет принимать за данные от родного датчика, но практической пользы от этого, на мой взгляд, мало.
ITMatika
02.09.2022 08:33Китайцы отреверсили протоколы и успешно продают копии WeDo 2.0.
По поводу кастомных датчиков/моторов для WeDo/Boost/Spike, имхо, интерес есть. Но может действительно, проще перейти на Ev3. Энтузиасты на ютубе выкладывают разные интересные поделки, комбинируя одинаковые или разные наборы. На мой взгляд, всё упирается в развитые сообщества и методические материалы. В подавляющем большинстве школ преподавание идёт по готовым схемам и возможностям одного конкретного набора. Хотя Lego и декларирует, что наоборот нужно развивать фантазию учеников, чтобы они самостоятельно придумывали новые собственные схемы.
nsk_artem
02.09.2022 00:54По поводу сообществ, к сожалению, не подскажу. По Ev3/NXT их раньше было очень много разной степени открытости, по WeDo в основном это детские проекты, а со spike/boost работать особо не довелось, пару раз только мельком их видел.
nsk_artem
01.09.2022 11:05+1Огромное спасибо за статью, очень интересно было читать!
Сам одно время занимался и разработкой электроники, и реверсом, и одноплатниками, но с существенно более низкой квалификацией, так как в компании, где работал, не было нормального разделения обязанностей, и приходилось всем делать всё (мои обязанности, например - разработка и изготовление схемотехники и плат, программирование МК/одноплатников, закупка компонентов, работа на станке).
С одной стороны, embedded - это круто, с другой стороны - очень сильно распыляешься, и в итоге страдают навыки.
С нетерпением жду рассказов про другие проекты, очень мало подобных материалов в интернете.
raspberry_pi_soft Автор
01.09.2022 11:14+1Спасибо за добрые слова! Совершенно с Вами согласен, когда касается реальной электроники, часто приходится становится универсалом. Тут есть и плюсы, начинаешь видеть всю систему целиком, от закупки комплектующих, приборов, изготовления "железа" до программного обеспечения. Можно переложить часть функций с электроники на программы и наоборот. И легче поставить задачу узкому специалисту-профессионалу при необходимости. Для Интернета вещей такое тоже важно, там ещё и серверная часть, сайт, вопросы поддержки всей системы и т.п. Буду писать ещё статьи, исходя из личного опыта.
DustCn
Зачем было снимать плату индикации, как я понимаю чисто сервисную, и затем городить её аналог на микроконтроллере, чтобы не пищало? Если достаточно было сдублировать сигналы идущие на нее на вход своего анализатора/логгера?
raspberry_pi_soft Автор
Насколько помню, плата индикации занимала много места, и очень хотелось от неё избавиться, чтобы больше места осталось для Raspberri Pi. Потом захотели более аккуратный адаптер RS-485 и желательно свой, в виде shield'a, как на картинке. Покупные мезонинные адаптеры для Pi чем-то не устраивали Заказчика. Заодно решили окончательно избавиться от писка. А так совершенно согласен, если бы знали заранее, что программными методами окончательно не избавимся, то логичнее было бы плату индикации оставить.