Reverse engineering a wireless burglar alarm, part 2

So we have some idea of the modulation and frequency used by the alarm from our initial investigations. That’s only part of the picture really – but at least we know this isn’t using frequency hopping or anything too challenging.

Where to go from here? We take it apart! I’m not even going to power anything up in this instalment – just see what the system is made up of.

The alarm consists of several components…

SL2 official image frrom allaboutelectrics.co.uk

  • A solar powered bell box on the outside wall, with flashing LEDs, PP3 and 6V sealed lead-acid batteries, and a tamper switch.
  • A keypad that mounts inside. This has 3 indicator LEDs, a tamper switch and is powered by a PP3 battery.
  • PIR detectors. These have a single red indicator LED, tamper switch and are powered by a PP3 battery.
  • Door contacts. These have a single red indicator LED, tamper switch, auxialliary contacts, and are powered by two CR2032 lithium batteries.

All use double sided PCBs, which appear well designed and are well made. Quality control stickers are on each board, as are small stickers on microcontrollers that look like firmware versions.

PIR

PIR

What do we see in here?

  • An Elan EM78P418N microprocessor (PDF datasheet). These are essentially Chinese PIC clones that have one-time programmable (OTP) ROM in them. Generally OTP ROM is cheaper than EEPROM. I don’t expect I would have much luck reading the code out as. It might have in-circuit debugging, but the documentation is poor and I have had no luck with other Elan micros.
  • An empty space for the crystal (X1), that indicates the Elan microprocessor is using an internal RC oscillator. This means that the microprocessor is not going to be doing anything requiring accurate timing, whether than be fast asynchronous protocols or waking at specific times. It does mean that at some point they considered using one – why would that be?
  • An empty space for an 8-pin device, U1. There aren’t many 8 pin devices in use these days, only really serial EEPROMS. Pins 1-4 are common and likely ground. The Elan microprocessor has no EEPROM. Optional EEPROMs are interesting – usually the microprocessor will check for the presence of the chip, then check for a “programmed” flag. If the EEPROM is not programmed, it will write the default values and set the “programmed” flag. I might be able to add an EEPROM and see what it could store.
  • A small RF daughterboard, with a TI CC1150 sub-1GHz transmitter (PDF datasheet) and 26MHz crystal. This is one of the CC11xx family – another well known member being the CC1110 SoC transceiver used in the GirlTech IM-ME. They are incredibly versatile and configurable. Importantly, we know that the PIR can only transmit, and not recieve. Many devices used a daughterboard for RF as I believe this can pass certification independent of the whole product and be easily re-used.
  • The rest of the components are the power supply or PIR detector.

Door Contact

DC

  • Another Elan EM78P418N microprocessor. It makes sense to use the same technology across the range if possible.
  • An empty space for a 8-pin SOIC again.
  • No empty space for a crystal – it was never a consideration to use an external crystal for this board.
  • The same RF daughterboard as in the PIR.
  • The coloured wires are my addition!

Keypad

CP

  • Yet another Elan EM78P418N microprocessor.
  • An 8-pin SOIC! HO18 08B1 – not much info on this. Pins 1-4 are grounded so I expect this to be a serial EEPROM.
  • No empty space for a crystal.
  • The same RF daughterboard again. This means the panel can only transmit, not receive. It is not aware of the state of other components,
  • The pin headers and wires are my additions.

Bell box

BB

  • An ATmega88 10MU122 microprocessor (PDF datasheet) – much more exciting (and much more familiar)! These use EEPROM and if the fuses are set right, I can read the EEPROM easily. I always find it interesting when products contain different processor architectures – maintaining two sets of code is an extra burden, so this choice is not made lightly.
  • A cylindrical can crystal with no markings – often these are 32.768kHz crystals for timekeeping. The ATmega88 has a internal RC oscillator which can be quite accurately calibrated, but nowhere near as accurate as an external crystal. Interesting how this is the only component with an external crystal.
  • No EEPROM or space for an EEPROM – probably because the ATmega88 has it built in unlike the Elan micros.
  • A 6-pin populated pin header – Atmel’s in-circuit programming connector is 6-pin. I wouldn’t ever expect anyone to open this and reprogram it though – so why is the header on there?
  • An RF daughterboard that is very similar – expect this time it is a CC1101 transceiver rather than just a transmitter. Interesting! This means that the only component of the alarm system that can receive and transmit is the bell box. This may have implications later.

Summary

So, for the RF side of things, all of the components are using the TI CC11xx chips. These support 2-FSK, fitting in with the findings in part 1. This is nice – I have worked with other systems using two or even three different RF frontends, and it makes things much more complex. We are also quite lucky – the CC11xx chips are very capable of frequency hopping spread spectrum at a high rate. We’re also lucky these aren’t the SoC versions as these have an AES encryption engine which makes strong encryption almost trivial.

Like Adam, I’d rather avoid RF. Luckily, the interface between the CC1101 and CC1150 is by SPI – I can simply sniff the connection between the RF daughterboard and microprocessor to see both the configuration and data. This is a privilege you don’t have if the CC1110 SoC is used – the transceiver and microprocessor are integrated with no easy way to access the config.

Next time, I will look at sniffing the SPI traffic between the microprocessors and RF boards.

Reverse engineering a wireless burglar alarm, part 1

After Adam’s recent post on reverse engineering a wireless doorbell, I thought I would take you through a similar process, but with a different system.

This is a Response SL2 wireless burglar alarm system, purchased from Amazon in late 2011. They seem fairly popular and well-reviewed.

We start our research without even touching the alarm, by using google. Their product page:

Operates on the 868MHz frequency with 20 Bit ID code and 1 million unique codes for added security

 So we already have a hint to where to look in the spectrum. Interesting how they say both “20 Bit ID code” and “1 million unique codes” – it is redundant information, but “20 Bit” sounds technical, so they probably add it for impact.

Notice that a number of keywords haven’t been used here:

  • Narrowband
  • FHSS
  • Spread spectrum
  • Rolling code
  • KeeLoq
  • Encrypted
  • Bi-directional

It’s likely that if the alarm used any of these, they would be making it known.

(As an aside, Friedland did initially tell me the SL series of alarms used rolling code – being a bit free and loose with specs seems to be common in the alarm world…)

DSCF7863

Let’s start off looking at this as if we couldn’t access any of the components. I’ll use my RF Explorer spectrum analyser to take a look at what is going on. The RF Explorer can be used standalone, but if you are next to a PC, the Windows client is really great and much quicker to use.

RF Explorer (wide)

I start by tuning it to 868MHz with a span of 5MHz. This will be wide enough to receive the transmission if it uses spread spectrum, multiple channels, or if the frequency is out. I trigger the alarm, and as you can see I end up with a broad peak at around 868.3MHz. Let’s go in further.

SL2 RF explorer2

Now I can see that I have two peaks, spaced about 100kHz apart. From this static image, you can’t clearly see what is happening over time – is this 2-FSK modulation (where data is encoded as two frequencies), or is it AM on two frequencies (rubbish frequency hopping spread spectrum)? The RF Explorer can’t really tell me – so it’s about time I whipped out my software defined radio

DSCF7865

Why did I start with the RF Explorer? The amplitude measurements are far more accurate and it can show me a much wider range (600MHz) of spectrum all in one go.

This is a TV tuner dongle. Some rather clever people worked out that it has a wideband RF frontend and can be tuned from about 25MHz to about 1750MHz, presenting us with a ~2.8Mbps baseband signal to work with. It is essentially the same as the FunCube used by Adam, but a lot cheaper. It does have some quirks and limitations though – it can be very deaf in certain areas and you see spurious signals due to the super-heterodyne design of the receiver.

SDR#

I can now see the signal from the alarm in a piece of software called SDR# – this not only shows me a spectrum analyser view (amplitude vs frequency), but also a waterfall diagram (frequency vs time). I can see that the two peaks are nearly continuous – I am likely dealing with 2-FSK modulation.

I can record the baseband signal and look at it in an audio editor as well:

Audacity screenshot

This clearly looks like data now.

At this moment, I have several options:

  • Use gnuradio to build a software receiver for 2-FSK. I will still be none the wiser to the protocol, and it will be receive only.
  • Crack open the alarm and take a further look…

Part two will show how I opened the alarm and started to work out what the system was doing….

An intriguing mix of micros

I’m working with a commercial product at the moment that consists of multiple wireless devices connecting to one another. Most systems I have worked on stick to a single microcontroller or RF frontend, or at least a single family of microcontroller and RF frontend.

Not this one.

Node 1 – A Texas Instruments MSP430F2132 as the microcontroller and an Analog Devices ADF7021 RF front end.

Node 2 – A Texas Instruments MSP430F1111A as the microcontroller and an Infineon TDK 5100 RF front end.

Node 3 – A Renesas H8/3008 as the microprocessor (yes, no integrated flash or RAM) and an Atmel AT86RF211SW.

All components were purchased at the same time, in fact, as part of a kit. They are all manufactured by the same company.

It amazes me that they could even work together. I just can’t understand why someone would architect a system like this. Any ideas?