RS-485 Anti-theft system commands

Some of you may have read on of my previous post, where I tried interpret the keypad print command.
If you did, well some of the interpretations I wrote on it were wrong.
This post is the second attempt to interpretate the dialogue exchanged between main board and the keypad.

After some researches and tests, I came out with the following, which if it is not the correct frame format, it is very close to it.

Each device connected to this bus, seems to follow this rule in the format of the frames produced.


Length is the first byte of each frame. It appears to be one byte long, which also means that a frame cannot be larger than 258 bytes including the length and checksum bytes. This does not seem to be a problem, all traffic I watched, no frame was longer than 25 bytes.

ADDR is the layer level address of the device. Few facts I noticed about the ADDR field:

• The address 0x00 seems to be reserved to the main board. All devices, when queried, simply answers to this address.
• Keypads are ranged from 0x10 to 0x1f (on the PCB of each device there are 4 deepswitch which can be used to select the low order four bits). The master keypad on the actual system must be the 0x10 address. In fact main board appears to send bytes directly to this address during normal operation.
• The RFID readers seem to be ranged at 0x50 and 0x5f.
• It seems there is some sort of multicast address ranged probably from 0xf0 to 0xff, not clear how does this work, but when mainboard starts, it seems to query 0xff. It also appears that 0xfe must be some sort of multicast directed to keypads. The keypad I have does not seem to recognize this kind of addresses btw.

CMD is the place where you tell to the addressed device what you want. Every device has its own mapped functions. No need to be discussed in this section.

DATA is the field where, if needed, the command data is placed. Not all commands have data, and if data is needed, it depends from the command.

Checksum is where a redundancy code is calculated to guaranty the integrity of the frame. The checksum is calculated on all the frame excluded the length field which is not included in the sum. Also I determined that this particular checksum can be calculated adding all bytes in a 16 bit integer and then checksum the 16 bit accumulator into a 8 bit value. eg. this frame tells a keypad to print "Hello World!" string in the upper line of the display. 1310140048656c6c6f20776f726c64212020202006 checksum is the last byte of the string an is calculated as: 
16bitsum(10+14+00+48+65+6c+6c+6f+20+77+6f+72+6c+64+21+20+20+20+20)=0501
8bitsum(05+01)=06

Keypad print string command

( Warning this is an early examination and interpretation of the data, some of the deductions I made are not accurate)
This is the first of a series of posts, where I'll try examine the list of commands I logged from a dialogue between the keypad and the mainboard.

Here the first: Print on display

A stream starting with the byte 0x13 seems to have the means of "print command".
This command seems to have a fixed length of 21 bytes.

Command example:

The following sequence prints on screen starting on top left: “Hello world!”

1310140048656c6c6f20776f726c64212020202006

0x13 print command

0x10 address of the first keyboard on the bus.

0x14 Unknown at the moment, but it must be present

0x00 the position 0x00 on the display, which means corner top – left

0x48,0x65,..,0x64,0x21,0x20,0x20,0x20,0x20 “Hello world!    ” 
0x06 checksum: 10+14+00+48+65+6c+6c+6f+20+77+6f+72+6c+64+21+20+20+20+20=>0501=>05+01=06

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*

Cisco 3500 XL fan subsystem failure.

It is quite old, yet still useful. I'm talking about an old Cisco 3500 XL series switch, I use every day in the lab of the company I work to. I don't want to talk about all the good points this switch has, but rather I'd like to talk about a failure it had, after almost 20 years it worked continously.
After all this years it broke its fan system.
It's summer, and if I want it last other 20 years, I had to fix it somehow.
The very first thing to do is understand how fan subsystem works.
Not the hardest task in the world, you just need to follow the tracks on the PCB from fan backwards to components.

Doing this you you'll identify the two main components the subsystem:
HP4410D: the  MOSFET used to command the power 5V circuit
TC648: the fan speed PWM controller.

One of those twos must be the broken one.
Roughly, the fan subsystem should look something like:

Both devices are packaged into a SOIC8 package, people skilled more than I am, are able to remove this package without damage the PCB nor the component using just iron. About me, I'm not that good and I had to use my cheap rework station.

Once the PWM controller is removed, it is possible to probe Vin. By using the TC648 datasheet you know that at this point tension should range from 1.25V to 2.65V, according to enviroment temperature.
In my case it was 2.4V which is a resonable.
With TC648 removed, the base of the mosfet is exposed to manual drive, I could therefore short Vout to Vdd and GND and observe fan spin at maximum rate, and fan to stop when Vout is put to GND.
This leaded me to the conclusion that  the MOSFET HP4410D had to be ok.
As counterproof, test the TC648 was a little more difficult since its package is not breadboard friendly.

Using this I could be sure the TC648 was broken, and than changing it I could fix my switch.
I hope someone else could found this article useful.