Hacking

Obviously, in most cases, proper "hacking", as in breaking in to someone's system without permission, is illegal.

However, it is quite fun to be able to do some "hacking" in the sense of working out how something works, and breaking in to it and doing things it was not designed to do. It is also fun to document how it works, even when it is using a protocol from the last millennium. In fact, in some ways, that is what makes it extra fun as it is nostalgic too...

So, today, I am playing with the Honeywell Galaxy alarm system. You see them everywhere - a very popular system. We use them, and slightly hate them to be honest. Even with full installer access they are impossible to make do some thing sensibly, even though they are actually very flexible. They have some really annoying quirks - like you can disarm the alarm using a key fob (good), but that does not also open the door, you have to use the key fob again to open the door. You can also set the alarm using the key fob (holding it to reader), but that also unlocks the door whilst doing it which may not catch (depending on type of lock). Little things like that just make it that extra bit annoying.

However, the actual bits that go with a Galaxy system are not bad - there is the keypad (as per picture) with display, the Max readers which work a door entry system, and RIOs which provide a range on input / output for sensors like reed switches and PIRs. They all sit on an alarm bus which is typically untwisted screened wire carrying 0V/12V power and A/B of an RS485 bus. Different panels have different number of busses and allow different number of devices.

My hacking today is understanding the protocol on that bus, and it has taken me most of the day. The main delay was many hours trying to work out how to make the RS485 USB lead switch to transmit and drive the bus. My mistake was assuming that I needed a a separate control like using RTS/CTS or some such (as some devices do). What I did not realise is the UART itself had a TXDEN output which does the driving and in fact I had a faulty cable - arrrrg. Change to different cable and you literally just write bytes to the port (from linux) and it enables the transmission side and sends them on the bus cleanly. Obviously that was the first thing I tried, but, faulty cable. It could not be simpler.

The nostalgia really has started to kick in though - I remember busses like this from, well, the 90s maybe, perhaps even earlier. We are talking standard serial protocol, 8n2 at 9600. The messages have no length indicator, just using timing to find end of message. There is a simple 1's compliment sum on the message for checking. No sequence numbers or acknowledgement or retransmission - it seems to use a state based logic, so sending the same message repeatedly until something needs to change. A really noddy and really old fashioned protocol. I suspect the "legacy" is strong with this one.

There are a few lovely quirks, like the keypad codes "0" to "9" as 0x40 to 0x49, but codes key "A" and 0x4B and key "B" as 0x4A, LOL.

Anyway, I have not only been able to work out the protocol but also send messages, even ones I should not be able to - like sneaking a status from a Max reader saying that someone has pressed the door exit button during the 10ms turn around time before the reader actually responds! Hence making a door open. Also sneaking in some messages to the keypad/display for fun, or changing the LEDs on the max reader. Basically, if you get access to a bus on one of these systems you can do all sorts.

OK, so why?

Well, I am thinking of making some open source linux code to work with the Honeywell / galaxy kit. Allow an open source alarm panel to be made, even. I suspect the protocol documentation and low level tools are what we would release, and maybe we make a high level panel and sell that as a solution, or maybe we make that open source, or like asterisk - a community designed alarm panel. Linux based would allow use of small industrial computer boards that could fit in a box with a PSU, battery and RIO. USB to RS485 allows plenty of busses with no problems. If you wanted to do something on the cheap you could even use a Raspberry Pi, but they tend to be less reliable than you would want for an alarm panel.

Of course this could allow a panel with modern config, using a web based interface.
It could allow integration with IT systems, like allowing SNMP of status feeding in to Nagios.
It could allow alarm state reporting by SMS, and email, even tweet DMs.

I suspect that getting insurers to be happy is a trick. We decided long ago that, at the office, contents insurance was more expensive that making the place secure. This applied even though we did have a burglary with several expensive machines stolen. So we do not have an insurance company breathing down our neck if we want a more custom alarm system. At home, the insurance company said the premium is no different, so they did not care if this was a custom alarm system or not. I suspect, even without insurance endorsed alarm system, there are plenty of opportunities for a system like this, and if it does get at all good and popular they may well endorse such a system. After all, the components are all proper off-the-shelf parts, standard RIO and PIRs and so on.

Of course, there are many other non alarm systems, such as purely door entry systems or time recording systems, which could use these same components.

What can I say? watch this space and we'll see what we can do.

First step is probably publishing the protocol.

It is fun.