Like all good tinkerers, [Andrew] decided to figure out how his wireless security system worked. Yes, it’s an exercise in reverse engineering, and one of the best we’ve seen to date.
After breaking out the handheld spectrum analyzer and TV tuner SDR, [Andrew] cracked open a few devices and had a gander at the circuit boards. The keypad, PIR sensor, and base station all used a TI radio chip – the CC11xx series – that uses SPI to communicate with a microcontroller.
Attaching a logic analyzer directly to the radio chip and reading the bits directly, [Andrew] started getting some very good, if hard to understand data. From the security system specs, he knew it used a ’20-bit code’, but the packets he was reading off the SPI bus were 48 bits long. The part of this code was probably the system’s address, but how exactly does the system read its sensors?
The easiest way to figure this out was to toggle a few of the sensors and look at the data being transmitted. With a good bit of reasoning, [Andrew] figured out how the alarm system’s code worked. This theory was tested by connecting one of the radios up to an Arduino and having his suspicions confirmed.
While [Andrew]’s adventure in reverse engineering is only a benefit for people with this model of security system, it’s a wonderful insight into how to tear things apart and understand them.
I was considering buying one of these (not exactly the same, but from the same range). All useful information, particularly if he picks up any vulnerabilities.
Having read his other posts, combined with the information in the posts linked here, I think I can say I wouldn’t feel safe with a Friedland alarm from that range. It looks pretty trivial to generate a disarm message after intercepting even a single communication of any type from a sensor. Could probably even automate it so that the receiver sees any sensor communication immediately be followed by a disarm.
The security on the alarm is token at best. I’ve not really got round to doing any posts on specific vulnerabilities, but most of the cheap wireless alarms can be jammed, triggered, disarmed or components otherwise spoofed with little effort. I used this Friedland alarm as an example as it is more interesting that say, the Yale wireless alarms that just use a microcontroller and AM OOK transmitter. They are also much more understandable than the ones that do use rolling code etc.
I also have to say – would the attacker you are trying to protect against actually use any of these weaknesses? I have used the TI Chronos watch to implement several attacks against these including active jamming (flipping a single bit stops the checksum validating, so nothing gets through). But no normal burglar would do this.
What happens if someone made and sold these devices on ebay? Then you need to worry.
But honestly, even if I hadn’t done this research, there are much, much better alarms for not much more money, based on features and usability. I don’t want to recommend one specifically.
I have moved onto researching signalling devices (that report your alarm status to receiving centres) as the alarm installer/manufacturer community seems more interested in them that consumer alarms.
If you could recommend a range or manufacturer that would be great. Is your reluctance due to not having personally tested whether the manufacturer is telling the truth, or simply a case of not wanting to upset one company by recommending another company’s products? (It seems like you’re in frequent contact with at least a few companies, so I see that being a genuine concern.)
Texecom Ricochet is a very cleverly designed product and I like the company – they actually respond to issues.
I have been threatened with legal action by some manufacturers unfortunately, which is why I can be a bit cagey.
Given how you’ve described certain companies’ response to issues, I’m not surprised they’d do that. Thanks for the tips though.
I quite like the Castle/Pyronix Enforcer as well, it has bidirectional radio which improves things a lot.
I don’t know if anyone else though the same when reading this but he has effectively laid out how to defeat wireless security systems. You could either do a man in the middle or a complete denial of service attack on it.
I was expecting at least a rolling code. The security (or complete lack thereof) in that range is so primitive it would be laughable (if it wasn’t meant to be protecting people’s property).
My first alarm was a Yale system – I was hoping to crack the rolling code on it. Turned out it was fixed ID. Got the Friedland one because they told me it was rolling code – turned out is was fixed ID. Even systems with rolling code often cock it up so badly that it doesn’t really matter.
For that specific system, I’ve shown that it might be vulnerable to certain attacks, yes. One other alarm system sends the pin from remote keypads to the control panel in the clear, and you can brute force via the same mechanism as the lockout is performed in the keypad, not the panel.
Some systems are better than others, but the Yale and Friedland systems are pretty poo.
Meant to be poor, but same sentiment.
In any case thank you for the extensive write up, very nice of you to take the time to do this.
No worries – I hope it inspires more people to get involved with reverse engineering.
I read through the whole set of posts. It was really really interesting to see how you broke down the process and what you were thinking at each stage, not to mention the tools involved. Thanks for taking the time to write that up.
These cheap wireless alarm systems are almost all pretty insecure.
– Most of them use a 8-bit to 32-bit “unique ID” for the sensors, which is transmitted when activated.
– A lot of them use this static unique ID also for the disarm remote (which makes replay attack possible).
– Most use FSK or OOK on a single frequency which is the same across the entire brand (easy sniffing, jamming, etc)
– Most sensors and code panels can only transmit, while the sirens just receive (and all the ‘brains’ are in the (outdoor) siren)
– Some even promise encryption or rolling code, while using just a static unique ID
Even something more expensive like ABUS makes all of above mistakes:
http://sitsec.net/blog/2012/05/10/reverse-engineering-the-abus-secvest-wireless-intruder-alarm-systems-radio-protocol/
I’ve been looking for a cheap and secure wireless alarm system for a while, but haven’t found anything yet. If I find the time, I would love to make an opensource one based on MSP430 chip. Don’t know if something open-source exists yet.
If you wind up going down this road, go for the CC430. It’s an MSP430 with a wirless core in chip. Olimex makes a nice little dev-board: https://www.olimex.com/Products/MSP430/Starter/MSP430-CCRF/. You could use something like Contiki or OpenTag as a base OS and go from there (that would simplify a lot of the RF architecture planning). Or if you’re comfortable at 2.4GHz the ATMEGA256RF is a pretty nice chipset as well. Dev-board: http://www.atmel.com/tools/ATMEGA256RFR2-XPRO.aspx and it supports the Atmel Lightweight Mesh Stack. I’ve been evaluating several of these platforms for work, and I really prefer the Atmel tools but we have a frequency requirement that’s a bit wonky.
All of this is very true.
The ABUS alarm is just a Cooper Scantronic rebadged.
Cooper told me that no one would bother reverse engineering a firmware image.
LOL.
Your average suburban burglar is gonna be way to dumb to figure this stuff out. And if you’ve got millions of dollars worth of art or whatever that might attract a higher class of crook, you’re not gonna scrimp on security eh?
Your average suburban burglar doesn’t need to figure this stuff out. All it takes is for your average ebay seller to decide there’s quick cash in selling alarm deactivation kits “for when you forget your code”, and it’s game over for an entire brand of alarms.
I agree with Kemp. But too much to say here, so I made a quick post:
http://cybergibbons.com/uncategorized/bumbling-burglars/
It is 1000 times easier to reverse engineer the protocol on the I2C side of the TI radio. Some scopes even have I2C decoders built in.
I’m a touch confused… how is sniffing an interface that isn’t used by the CC1150 using a clunky expensive scope that would then need further decoding “1000 times easier” than sniffing the SPI interface using a $100 logic analyser and using a simple software decoder to give me direct results?
My alarm, (keeping the brand my little secret) detects wireless jamming attacks (the alarm goes off and it throws a flag), has true rolling codes and after a couple of tries at “guess the code”, the alarm goes off as well. But someone could sure build a device to make life miserable with false alarms!
Would you be happy sending me an email to tell me what alarm this is? web2013 @ cybergibbons.com or via the contact form on the site, or via twitter DM @cybergibbons
The reason I ask is that I haven’t seen any alarms with really robust jamming detection. Passive detection, as mandated in the standards, is a waste of time – alarms that only meet this spec can be fooled by a 50% duty cycle modulated signal. Active detection (i.e. what % of packets get through) is OK, but often just flipping a couple of bits will cause problems.
Rolling code implementations tend to be pretty poor, largely due to rubbish PRNGs which aren’t randomly seeded
Have you independently verified the alarm’s claims?
Um yes I have a problem sending you information that you could use to blackhat my security system, flip that into a product that you could sell or leak to jerkoffs that would also use to exploit my alarm. also you state on your blog that “There is no requirement for alarms to be independently tested.” Um UL and ANSI both have specs which are mandated to be met in order for your insurance company to be happy with your alarm system. Required no, but if you want to be covered by your insurer you better meet those specs. At lease where I live. And while yes, people white hat as well to “help” expose security flaws so that they may be fixed, BUT you can’t “proof” anything and everything. People will find a way to break any security system or safe guard on anything, so let the bad guys keep trying on their own. My job requires a lot of trying to make things idiot proof, but they keep making better idiots. SO holding your cards to your chest is another tactic. I know, I know, “if I don’t exploit it and leak it to the world, someone else will with worse intentions”. Well the world and certainly the bad guys don’t need your kind of “help”. EOM
Where in the UL or ANSI specs is it a requirement for third party testing?
Seems like you don’t have much confidence in your alarm being secure for some reason.
Let’s be honest here, he’s not going to give a coherent answer to any questions. Let the people who are willing to learn about good alarms learn, and those who want to live in a bubble live in a bubble. C’est la vie.
Yeah, I just looked at some other posts by him/her…
Thanks for putting this article up. I was just looking into using the CC11XX transcievers for a project. Perfect Timing.