Reverse of the AC48 RS485 protocol from Perco. Keep the lines of your access control system from invasion

By participating recently in various interesting projects, the problem of the alternative management of the Perco product has emerged. Electronic pass-through KT02.3 . This product is a complete solution and does not imply the use as part of other access control systems, as well as any intrusion into its control environment. But, as the saying goes, “Everything is possible! The impossible just takes more time. ”(C) Dan Brown .

But we did it. How it all happened read under the cut.

The basic description of the system can be found here from this document .

Let us dwell on the external interfaces of the system:

Supports connection via RS-485 interface to the following devices:
• up to 8 lock controllers PERCo-CL201 (the CL201 controller has a built-in reader and provides control of one lock);
• system time display PERCo-AU05
• card reader PERCo-IC02.1 (for wiring diagram, see description of PERCo-IC02.)

This means that a sufficient number of peripheral systems that provide access to the premises can be connected to the common bus of this turnstile.

Communication interface with PC and other controllers of the S-20 system - Ethernet (provided by
TCP / IP protocol stack support (ARP, IP, ICMP, TCP, UDP, DHCP)).

Managed through its application, available for download from the site. It also has a very tricky SDK, closed by the NDA.

“The delivery of the SDK provides for the signing of an agreement on non-disclosure of confidential information with the interested party and is free.”

Since neither the turnstile circuit nor access to the SDK was available to me, armed with a soldering iron and RS485 transceiver, we began to study how the protocol works.
')
The wiring of external devices is quite trivial.

You can connect:

• RU - radio control
• Remote control - remote control
• DKZP - Sensor of control of an area of ​​passage
• Siren
• up to 8 locks PERCo-CL201
• PERCo-AU05 system time display

No other devices can be connected.
The Perco protocol is closed, but there is a description of the PERCo-AU05 watch, which is easily googled on the network.



This picture from the description is the only mention of the PERCo protocol found on the network.
Fine. There is a piece of protocol, which means you can see what runs there. We connect RS485 to the turnstile and look.


In principle, it is generally not clear how this works. Who is the sender, who is the recipient? Where what, what is terminated? Just a stream of some binary data.
Having gone around with the dumps for several days, I realized that "the devil is sitting in the details."
The result was the following byte structure inside the reader packages:

• 1. 0xAA - the command start code
• 2. 0x [02] [12] - reader ID
• 3. 0x0 [15] - command code
• some data
• CRC16 checksum

What next?
Who sends this? What is the answer from this?
It turned out that everything is much more cunning than we used to see in session protocols.
To understand this, readers and a controller had to be connected to a break through two RS485 converters.
So, in fact, the package consists of two parts. The first part is the controller command, always starting with 0xAA , the second part is the device response to which the command belongs . This response has a variable length and ends with the checksum of the entire packet.
In reality, the “controller-reader” session looks like this:

Let's sort some combinations.

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

The controller sends the command '0x1A' to the reader with the identifier '0x01' and the data '0xFF' , to which the reader responds with some code. It would seem “Here! it! take it and do it, but no.
The manual says that the last two bytes of the packet are the checksum of the entire packet with the exception of the command code, using the CRC16 algorithm. Counting CRC16 from ['0x01', '0x1A', '0xFF'] on the calculator and we get 0xE01A , which does not converge with 0x1FE5 . It turns out the valiant developers of PERCo made a little protection either from line noise, or from people like me;)
The fact is that 0x1FE5 , this is 0xE01A xor 0xFFFF, and of course this is not written anywhere (see the manual above).
So, with the package from the controller, everything is more or less clear, what exactly is the reader with the address 0x01 sent?
Looking through the data inside the packet from the controller and incrementally counting the CRC16, it turned out that the reader's response ['0x7f', '0xa4'] is the checksum of the second and third byte ['0x01', '0x1A'] .
Thus, the reader tells the controller that it is “live”.

Then everything is the same. The command ends with CRC16 and CRC16 from the second and third byte of the command.

Let us dwell on the addressing of external devices.

As you can see from the dump, all external locks are bit-addressing, hence the limit of 8 external locks is obtained.
After the completion of the initialization of all available devices, the controller on the reader resets the indication

The controller command 0x1B resets the reader, and the command ['0x48', lamp] lights the light bulb, where lamp has values.

• 0x01 - green
• 0x02 - orange
• 0x04 - red

After the readers are initialized, the controller checks their status again.

and starts a generator of polling the status of readers and locks.
The reader is polled 3 times per second each.
And now the fun begins.
At the status request, the reader ADDITIONS the controller's command with data from its buffer, counts CRC16 xor 0xFFFF and provides data to the communication channel.
Consider a reader response packet:
Empty package: readers: ['0x4e', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0x00', '0xf1', '0x6e']
Package with map: readers: ['0x45', '0x40', '0x5d', '0x7a', '0x07', '0x00', '0x04', '0x00', '0x00', '0x00', '0xbb' , '0x9d']

• The 1st byte is the packet number, which is calculated by incrementing the previous value of a random number from the range from 1 to 15, after which the value is taken modulo 79 (0x4F)
• 2nd byte is the reader state. If there is 0x00 , then the reader's buffer is already read by the controller, if there is 0x40 , then there is a card in the buffer.
• From 3rd to 6th byte the code of the read card is placed.
• In 7 bytes, the number 4 always lives. I did not understand the remaining bytes.

If the controller has an attached card, then the controller issues a command to the reader to accept the card code, lights the green lamp and opens the passage mechanism. When the waiting time expires or when the user passes, the passage mechanism closes and the status of the reader is reset to its original state. In this survey of other devices does not stop.

And now, in fact, what was implied in the title about “Protect the lines of your ACS from invasion”?

The interceptor written by me in Python allows you to seize control of the PERCo ACS at any point of the RS485 trunk and track the cards to which the turnstile gives access authorization, interrupt data transfer from the reader to the turnstile controller with the base of valid keys, open any devices connected to the data highway. At the same time, the “left” cards applied to the readers of the system can be replaced by “valid” cards and vice versa. By removing the initialization block dump and scrolling it back into the line, you can emulate both the controller and readers, which opens up simply endless possibilities for managing the system.

So "Take care of the lines of your ACS from invasion" :)

PS: I will not upload scripts :-P

© Aborche 2016