Anti-theft system keypad

In this post I want to log my experience in reverse engineer the protocol used in ROKONET and possibly other manufacturers' anti-theft system peripherals.

Somewhere in the past I bought an anti-theft system for my home, but because I'm a systems nerd, I chose one which claims it can be interfaced with computers in a computers network.
Unfortunately, what I got after my purchase, was very different from my expectations!
 

I got a closed system which could be configured through an IP network using its manufacturer's proprietary software running only under MS-Windows. If this was not enough, manufacturer won't assist end-users, that because the system is not meant to be installed or configured by the end user, but it have to be installed and configured only by manufacturer authorized personnel. However, if enduser wants, he can buy it and then arrange himself a solution.Very disappointing.

In spite this system cost me good money, it remained in a dusty drawer for a long time, until I found the time to work on it.
Now I'm here logging my progresses on this matter and sharing them with the world, hoping those can be useful to someone other than me.

The big picture is to open the anti-theft systems to the world of the open source, letting open source software such as Asterisk, Motion, Zone Minder and guess you what, integrates with proprietary hardware such as keypads, RFID scanners, PID sensors, proximity sensors, and other anti-theft systems specific hardware.

I'm still far from the target, but at least let dreams fly high!

Back on Earth,  let's start with something, let's start with a keypad, the most common piece of hardware every anti-theft system should have.

Manufacturers divide peripherals in two main classes: dumb and intelligent. To "dumb" class belong for example sensors such as PID, contacts and all the sensors which communicates with just a open-closed contact communication. Intelligent ones such as keypads, RFIDs and audio systems use so called "BUS" for connecting the main board of the system.

Keypads belong to the latter class so the first step is to identify what this, so called "bus", actually is.

BUS is a 4 wires line which connect more than one peripheral to the main board of the system.
Usually these 4 wires have a fixed color scheme, which is RED, BLACK, YELLOW and GREEN.
This color scheme is wide spread among vendors and manufacturers, and it seems to be a de facto standard among anti-theft system.
Hypothesis is that this so called BUS is nothing more than an half-duplex RS-485 implementation and a couple of wires with power supply.

A close look at the circuitry seems to confirm this hypothesis.

You can see on the board distinctly the RS-485 driver SP485EC which connects directly to the keypad MCU UART pins.

Looking at the RS-485 input circuitry, you can find two of the best practise the rs-485 designer have published: fail safe resistors (a pull-up and a pull-down resistor) and two diodes operating as transient overcurrent protections.

It is now important to familiarize with the data passing over this connection.
To do this, my first guess has been trying to sniff the data on the wires.
A simple guess (9600,8,n,1) of the serial settings an I had a dump of bytes main board and keypad are exchanging.
Beware, the fact that you can read from a serial stream, and that data you read is meaningful or correct, DOES NOT mean you have the correct serial setting.
At the time I didn't know this detail yet, and it cost me several hours struggling on why I couldn't transmit anything to the keyboard.

Here you can see a comparison between my generated message (bottom), and the same  generated by the original main board (upper).
Several hours later, I finally found that this particular setup wants a serial setting with 2 stop bits, which means 9600,8,n,2 and not 9600,8,n,1.

Another problem is that sniffing from an half duplex dialogue made on the same pair, gives you a detailed list of bytes exchanged, but doesn't give you any information about direction of those bytes, nor the timing.

Sniff data on the UART pin on the MCU gave me a better understanding fo that dialogue.
Using this I finally could get a precise list of messages exchanged between main board and the keypad.
Here for you an piece of the message exchanged between those two. I indicated with *xxx* messages originated by the keypad.

02ff0404
02101a2a                                                   *0200a3a3*
0310058095                                                 *02002323*
02030407
02050409
02500454
0285078c
020a040e
03fe168095
13fe140050524f4752414d4d415a494f4e453a209c
13fe1410534953542e204e4f4e2050524f4e544fa5
02fe1a19
02101a2a                                                   *02002323*
031019022b                                                 *02002323*
041022031146                                               *02002323*
041018000028                                               *02002323*
131014000000000000000000000000000000000024                 *02002323*
131014100000000000000000000000000000000034                 *02002323*
0310160026                                                 *02002323*
02030407
02050409
02500454
04850f01099e
0285078c
020a040e
03fe168095
13fe140050524f4752414d4d415a494f4e453a209c
13fe1410534953542e204e4f4e2050524f4e544fa5
02fe1a19
02101a2a                                                   *02002323*
041022031146                                               *02002323*
02030407
02050409
02500454
04850f01099e
0285078c
020a040e
03fe168095
13fe140050524f4752414d4d415a494f4e453a209c
13fe1410534953542e204e4f4e2050524f4e544fa5
02fe1a19
02101a2a                                                   *02002323*
04101820236b                                               *02002323*
1310140050415254495a494f4e45203120202020fd                 *02002323*
1310141020202020414c4c41524d45202020202055                 *02002323*
03101680a6                                                 *02002323*