Участвуя последнее время в разных интересных проектах, возникла задачка альтернативного управления продуктом Perco Электронная проходная KT02.3. Данный продукт является законченным решением и не подразумевает использование в составе других систем СКУД, а также какого-либо вторжения в свою среду управления. Но, как говорится в поговорке, «Возможно все! На невозможное просто требуется больше времени» (С) Дэн Браун.

Но мы сделали это. Как всё получилось читайте под катом.

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

Остановимся на внешних интерфейсах системы:

Поддерживает подключение по интерфейсу RS-485 следующих устройств:
• до 8-ми контроллеров замка PERCo-CL201 (контроллер CL201 имеет встроенный считыватель и обеспечивает управление одним замком);
• табло системного времени PERCo-AU05
• картоприемник PERCo-IC02.1 (схему подключения см. в описании PERCo-IC02.)

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

Интерфейс связи с ПК и другими контроллерами системы S-20 – Ethernet (обеспечивается
поддержка стека протоколов TCP/IP (ARP, IP, ICMP, TCP, UDP, DHCP)).

Управляется через своё приложение, доступное для скачивания с сайта. Так же имеет очень хитрый SDK, закрываемый NDA.

«Поставка SDK предусматривает подписание с заинтересованной стороной соглашения о неразглашении конфиденциальной информации и осуществляется бесплатно.»

Так как ни схемы турникета ни доступа к SDK у меня не было, вооружившись паяльником и трансивером RS485 мы начали изучать как устроен протокол.

Схема подключения внешних устройств довольно тривиальна.

Можно подключить:

• РУ — радиопульт
• ПДУ — пульт дистанционного управления
• ДКЗП — Датчик контроля зоны прохода
• Сирену
• до 8 замков PERCo-CL201
• табло системного времени PERCo-AU05

Никаких других устройств подключить нельзя.
Протокол Perco является закрытым, но есть описание часов PERCo-AU05, которое легко гуглится в сети.



Данная картинка из описания это единственное упоминание протокола PERCo найденное в сети.
Отлично. Кусок протокола есть, значит можно посмотреть, что там бегает. Подключаем RS485 к турникету и смотрим.


В принципе вообще непонятно, как это работает. Кто отправитель, кто получатель? Где что, чем терминируется? Просто поток каких-то бинарных данных.
Провозившись со снятыми дампами несколько дней, я понял, что «дьявол сидит в деталях».
Получилась следующая структура байт внутри пакетов для считывателей:

• 1. 0xAA — код начала команды
• 2. 0x[02][12] — идентификатор считывателя
• 3. 0x0[15] — код команды
• какие-то данные
• контрольная сумма CRC16

Что же дальше?
Кто это отправляет? Что из этого ответ?
Оказалось, что всё намного хитрее, чем мы привыкли видеть в сессионных протоколах.
Для понимания этого пришлось подключить считыватели и контроллер в разрыв через два конвертора RS485.
Так вот, на самом деле пакет состоит из двух частей. Первая часть — это команда контроллера, всегда начинающаяся с 0xAA, вторая часть — это ответ устройства к которому относилась команда. Данный ответ имеет переменную длину и заканчивается контрольной суммой всего пакета.
В реальности сессия «контроллер-считыватель» выглядит вот так:

Разберем некоторые комбинации.

cntrler:['0xaa', '0x01', '0x1a', '0xff', '0xe5', '0x1f']
readers:['0x7f', '0xa4']

Контроллер посылает команду '0x1A' для считывателя с идентификатором '0x01' и данными '0xFF', на что считыватель отвечает каким-то кодом. Казалось бы «Вот! оно! бери и делай», ан нет.
В инструкции написано, что последние два байта пакета это контрольная сумма всего пакета за исключением кода команды, по алгоритму CRC16. Cчитаем CRC16 от ['0x01', '0x1A', '0xFF'] на калькуляторе и получаем 0xE01A, что никак не сходится с 0x1FE5. Оказывается доблестные разработчики PERCo сделали небольшую защиту или от помех в линии, или от таких как я ;)
Дело в том что 0x1FE5, это 0xE01A xor 0xFFFF и об этом естественно нигде не написано (см. мануал выше).
Итак, с пакетом от контроллера всё более менее понятно, что же такое прислал считыватель с адресом 0x01?
Перебирая данные внутри пакета от контроллера и пошагово считая CRC16 оказалось, что ответ считывателя ['0x7f', '0xa4'] это контрольная сумма второго и третьего байта ['0x01', '0x1A'].
Таким образом считыватель говорит контроллеру, что он «живой».

Дальше всё так же. Команда заканчивающаяся CRC16 и CRC16 от второго и третьего байта команды.

Остановимся подробнее на адресации внешних устройств.

Как видно из дампа, все внешние замки имеют битовую адресацию, отсюда и получается ограничение в 8 внешних замков.
После окончания инициализации всех доступных устройств, контроллер на считывателях сбрасывает индикацию

Команда контроллера 0x1B резетит считыватель, а команда ['0x48', lamp] зажигает лампочку, где lamp имеет значения.

• 0x01 — зеленый
• 0x02 — оранжевый
• 0x04 — красный

После инициализации считывателей, контроллер еще раз проверяет их состояние

и запускает генератор опроса состояния считывателей и замков.
Опрос считывателей происходит 3 раза в секунду каждый.
А теперь начинается самое интересное.
На запрос состояния, считыватель ДОПОЛНЯЕТ команду контроллера данными из своего буфера, считает CRC16 xor 0xFFFF и выдаёт данные в канал связи.
Рассмотрим пакет ответа считывателя:
Пустой пакет: readers:['0x4e', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0xf1', '0x6e']
Пакет с картой: readers:['0x45', '0x40', '0x5d', '0x7a', '0x07', '0x00', '0x04', '0x00', '0x00', '0x00', '0xbb', '0x9d']

• 1й байт это номер пакета, который вычисляется путём приращения к предыдущему значению случайного числа из диапазона от 1 до 15, после чего берется значение по модулю 79(0x4F)
• 2й байт это состояние считывателя. Если там 0x00, то значит буфер считывателя уже прочитан контроллером, если там 0x40, то значит в буфере имеется карта.
• с 3го по 6 байт помещается код считанной карты.
• в 7 байте всегда живёт цифра 4. Остальные байты я не разбирал.

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

А теперь собственно, что подразумевалось в заголовке про «Берегите линии своих СКУД от вторжения»?

Написанный мной на языке питон перехватчик позволяет захватить управление СКУД PERCo в любой точке магистрали RS485 и отследив карты на которые турникет выдаёт разрешение прохода, прерывать передачу данных от считывателя к контроллеру турникета с базой валидных ключей, открывать любые устройства подключенные к магистрали данных. При этом «левые» карты прикладываемые к считывателям системы, могут заменяться на «валидные» и обратно. Сняв дамп блока инициализации и прокрутив его обратно в линию можно эмулировать как сам контроллер, так и считыватели, что открывает просто безграничные возможности для управления системой.

Так что «Берегите линии своих СКУД от вторжения» :)

PS: скрипты выкладывать не буду :-P

© Aborche 2016