Sunday, October 2, 2016

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: 

Thursday, September 29, 2016

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!”

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.

02101a2a                                                   *0200a3a3*
0310058095                                                 *02002323*
02101a2a                                                   *02002323*
031019022b                                                 *02002323*
041022031146                                               *02002323*
041018000028                                               *02002323*
131014000000000000000000000000000000000024                 *02002323*
131014100000000000000000000000000000000034                 *02002323*
0310160026                                                 *02002323*
02101a2a                                                   *02002323*
041022031146                                               *02002323*
02101a2a                                                   *02002323*
04101820236b                                               *02002323*
1310140050415254495a494f4e45203120202020fd                 *02002323*
1310141020202020414c4c41524d45202020202055                 *02002323*
03101680a6                                                 *02002323*

Thursday, September 8, 2016

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.

Wednesday, December 30, 2015

Fiat Panda windscreen wiper timer

My Panda, after almost 16 years of service, begins to show its years.
This time, the front  wiper does not work properly.
You may read almost evreywhere, Google is your friend....
About this matter, it seems nobody ever went deeper, and to my issue, which seems to be quite widespread, Google wouldn't helped that much; the only answer I found by it is "change the motor and its controlling circuit". This solution can be quite expansive, looking around for prices,  it seems you can not find it for less than 100€.
On the other hand, looking at the controlling circuit, it does not seem to be very complicated, so I decided to use some time to resolve my issue, and therefore save 100€.

As from the image I included in this post, circuit itself is not too complicated.
I also made some schemas to help myself in understanding its behaviour.

The switch appearing in the bottom of the schema, is embedded in the gear inside the transmission of the motor. Its rotation make the controller understand about the wiper position. It is a plastic gear with the core made of conductor material. It appears as follow:
Where the RED part is the metallic core, and the black lines is where contact from the control circuit goes.

Well, I guess this is the time where I tell you which is my problem, after all.
Problem is as follow:  the "SLOW" speed of the wipers does not work, and when it is set to the "FAST" speed, if you turn off the wiper it stops where it is, without return to its home postion.
After several hours of analysis, I found where the problem lies.
It is due to the oxidation of the normally open contact of the relay.

This way I saved myself more than 100€ for the spare part, I hope anyone else could found my info useful and save his money.

Friday, December 11, 2015

Block aggressive advertising calls

In my country, but I bet anywhere else do the same, the telephone calls for proposing new products are constantly increasing, these annoying calls, sometimes malicious, aren't always welcome.

My country has adopted a kind of institutional way to handle this phenomena, it is called  "registro pubblico delle opposizioni", using this, any citizen may publish his telephone number, merely this action should him guarantee he would never ever receive again any advertisement call.

Unfortunately, reality can't be more distant from what really is going to happen.

Telephone spammers do not use to follow rules, and the weak statement "this user does not want to be called for commercial purposes "  is not enough to prevent they to call you. 

If you do not want to be called, you have to find yourself a way to do that.
In other words, you have to find a way to recognize them as spammer, and forward them, for example, to an announce stating you do not want to be called.

As an Asterisk user I have a framework at my disposal, which potentially lets me route calls using any sort of policy; but the main issue is how to identify a spammer?

Internet community, seems to have faced this problem and has built a kind of database in which people complaints about telephone numbers.

It exists, for example, a service called TELLOWS on which anyone can leave a comment on a source telephone number.

So why don't use those information to identify spammers and avoid unwanted telephone calls?

My proposal is integrate the service provided by TELLOWS in the Asterisk dialplan.

Here an example of my thougths.

in the Asterisk dialplan
exten =>  incoming,       1,              Noop(Incoming call is just arrived)
exten =>  incoming,       n,              Set(tellowsc=${SHELL( ${CALLERID(num)})})
exten =>  incoming,       n,              GotoIf($[${tellowsc}>1]?reject)
exten =>  incoming,       n,              Dial(${destination},30,${FLAGS})
exten =>  incoming,       n,              HangUP()
exten =>  incoming,       n(reject),      Answer()
exten =>  incoming,       n,              Wait(2)
exten =>  incoming,       n,              Set(CDR(userfield)=RejectedByPolicy)
exten =>  incoming,       n,              Playback(spam)
exten =>  incoming,       n,              HangUP()
the bash script for the italian version of TELLOWS
score=$(wget -O - -q "$1" | grep "/images/score/score[0-9].png" | grep scoreimage | sed -r 's/.*score([0-9])\.png.*/\1/');
comments=$(wget -O - -q "$1" | grep "itemprop" | grep "Numero di commenti:"| sed -r 's/.*>([0-9]+)<.*/\1/');
echo -n "$comments";
I used, to reject calls, the number of comments the number has, but there's also a kind of number score, you can use to take your decision

Thursday, October 22, 2015

JabberSend crashes your system if it has no connection with the XMPP server.

JabberSend is quite a useful function.
It lets you send xmpp instant messages, and it can be used for various things such as alert you when a call hits your voice mail or also that someone is calling you.

Here an example dial plan.
exten =>  s, 1,  Noop(Incoming call is just arrived)
exten =>  s, n,  JabberSend(XMPP_Account,Jid@domain,Incoming call from "${CALLERID(num)}")
exten =>  s, n,  Dial(${GLOBAL(incoming_call_group)},30,${FLAGS_incoming})
exten =>  s, n,  JabberSend(XMPP_Account,Jid@domain,${CALLERID(num)} is leaving VM message)
exten =>  s, n,  VoiceMail(${GLOBAL(incoming_voicemail)}@asterisk)
exten =>  s, n,  Hangup()

Nice feature, but it comes with a big problem: if for any reason the XMPP connection is down, JabberSend crashes your Asterisk system.
This kind of behaviour is obviously not admittable in any kind of production environment.

You can however use it in a production environment making a slight modification to the code source code of res_xmpp.c

In the Asterisk version I'm using, the 11.6, modifying the function xmpp_client_send_message as follow, the result is:
if JabberSend is invoked and there's no connection to the xmpp server it logs a warning message instead of crashing the system.

here the code, the red indicates where I modified the original code:
static int xmpp_client_send_message(struct ast_xmpp_client *client, int group, const char *nick, const char *address, const char *message)
        RAII_VAR(struct xmpp_config *, cfg, ao2_global_obj_ref(globals), ao2_cleanup);
        RAII_VAR(struct ast_xmpp_client_config *, clientcfg, NULL, ao2_cleanup);
        int res = 0;
        char from[XMPP_MAX_JIDLEN];
        iks *message_packet;

        if (!cfg || !cfg->clients || !(clientcfg = xmpp_config_find(cfg->clients, client->name)) ||
            !(message_packet = iks_make_msg(group ? IKS_TYPE_GROUPCHAT : IKS_TYPE_CHAT, address, message))) {
                return -1;

        if (!ast_strlen_zero(nick) && ast_test_flag(&clientcfg->flags, XMPP_COMPONENT)) {
                snprintf(from, sizeof(from), "%s@%s/%s", nick, client->jid->full, nick);
        } else {
                snprintf(from, sizeof(from), "%s", client->jid->full);

        iks_insert_attrib(message_packet, "from", from);

        if (client->state == XMPP_STATE_CONNECTED) {
                                                    res = ast_xmpp_client_send(client, message_packet);
                                              else {
                                                    res = -1;
                                                    ast_log(LOG_WARNING, "XMPP: Not connected, unable to send messages to %s\n", client->name);


        return res;
I hope this can help.