Reverse engineering a wireless burglar alarm, part 7

So, where were we? We’ve worked out how several components of the alarm use the CC1150 to send out signals, and now I want to emulate the signal and then play with it.

By far the easiest way to do this is to use the same CC1150 chip as in the authentic transmitters. I can be absolutely sure the 2-FSK modulation with ~50kHz deviation will be reproduced exactly. There are many other RF transmitter chips out there that can do this, but we know that these work and we already have the correct settings.

So, the first challenge is – where do I get a board with a CC1150 on it? Well, we have plenty of alarm sensors with neat little CC1150 daughterboards on them!

Door contact RF board

Door contact RF board

I chose a door contact as my victim – they are the cheapest and simplest sensors.

The daughterboard has an 8-pin interface, with a 0.1″ pitch pin header connecting the two. I need to desolder the board to use it. Desoldering pin headers is always a pain – you can’t desolder all 8 pins at a time. My technique now is:

  1. Chop the pin header along it’s length, separating the two boards. I have a nice pair of snips for this, but a Dremel with cut-off wheel can do it if they don’t fit.
  2. Chop the plastic spacer away from the pins, leaving you with just half the pins stuck in the board.
  3. Desolder the pins one at a time.

The daughterboard

Now I have a small CC1150 board. I soldered a new pin header onto it, and a pin socket onto the rest of the door contact. This allows me to easily reconnect it to the door contact if I need to.

You’ll notice in the picture above that there is a small bridge wire. I desoldered and resoldered the CC1150 QLP package (just to see if I could) and burned a track in the process.


Testing testing 1-2

Now we need to drive this board using something. There are a plethora of options available to me:

  • An Arduino board
  • A mbed board
  • A Bus Pirate
  • A GoodFET
  • A CC1110 development board (this would skip using the CC1150 board, as it has a built-in transceiver)
  • One of the Ciseco CC11xx boards (again, this would skip the CC1150 board)
  • Any of the other development boards I have lying around…

I decided I would use an Arduino board – specifically the Seeeduino Mega.

Why the Arduino? In reality, I’ve stopped using the Arduino environment and now use AVRGCC, so this is really just a nice little AVR development platform.

It won out over the mbed as I have had SPI issues with the mbed before.

The Bus Pirate and GoodFET are very similar, but require a host PC. I would like this standalone.

It seemed silly to implement this on a CC1110 chip, and I have had problems in implementing proprietary encoding schemes on it before.

Why the Mega? I find myself often using the extra pins and RAM as compared to the ATmega328p used in the Uno

So, now I have a RF board and something to control it. Next, I need to connect the two and write some code!

Reverse engineering a wireless burglar alarm, part 6

Last time, we looked at the data the door contact was sending out over the airwaves. We arrived at a simple encoding system where 0 = 100 and 1 = 110. This might not be entirely correct, but we are finding 48 bit long packets containing the same data each time.

Now we need to try and work out what these bits represent.

As we worked out in part 4, all of the automated packet control in the CC1150 has been bypassed. This means that the microprocessor must deal with everything. What is everything? What does a normal packet look like in a simple RF system?

There can be a number of components sent. In approximate order, from start to finish:

  • Pre-amble – generally a series of 10101010. The purpose of this is to make the receiver aware that a transmission is happening, adjust the gain as required, and synchronise clocks. The average value of this signal is partway between 1 and 0, which will mean the gain is appropriately set to receive both 1s and 0s.
  • Sync-word – sometimes a sync word is sent immediately after the pre-amble. This is similar to an address or ID, but often it is system wide.
  • Packet length – if the packet length is variable, then the receiving system needs to know how long the packet should be. Even if packet length appears fixed, the protocol may accommodate for variable length packets.
  • ID – each device must be uniquely identifiable. We already know this is 20 bits long i.e. just over 1 million unique IDs. Sometimes other data is encoded in the ID, such as sensor type or manufacturer. This effectively reduces the keyspace, and makes guessing IDs easier.
  • Data – this is the data such as triggered/not-triggered, sensor type, battery state, tamper state and so on.
  • Checksum – often a checksum is calculated on the other other bits, so that the receiver can detect errors (and sometimes even correct them). On simple uni-directional RF systems used for safety that retransmit huge numbers of times, checksums become less useful.

Working out which piece of the data is which involves careful prodding of multiple components and observation of changes. Let’s get going!

It’s quite time consuming running a logic trace, exporting the data, running it through my parser, and interpreting the results. I should really learn to write analyser plugins for the Saleae Logic software, but my last attempt never quite worked right.


First thing I notice – there is no variation from packet to packet. There is no rolling code used here.

Door contact 1

The contact only transmits RF when the button is released (tamper) or the magnet removed (door open). There is therefore no indication to the rest of the system that a fault condition has been removed or a door closed. There appears to be no low-battery signal sent either.

These are the two transmissions

001100001100100011000000010100000000000000010000 - DC1 t
001100001100100011000000010100000000000000100000 - DC1 a

Notice only a couple of bits vary (shown in red)

Door contact 2

001100001101000000010000010100000000000000010001 - DC2 t
001100001101000000010000010100000000000000100001 - DC2 a

Again, only a couple of bits vary – the same bits as with door contact 1.

Let’s compare door contact 1 and 2:

001100001100100011000000010100000000000000010000 - DC1 t
001100001101000000010000010100000000000000010001 - DC2 t

The first 4 bits are the same between the two sensors. Is this the pre-amble and sync?

We then have a few bits that differ. This could be part of the ID.

The last bit also differs (green). Notice how 10 bits are high in the first packet, and only 9 in the second. This could mean that the last bit is a parity bit, a very simple checksum.


001100011101111101100000010000000000000000010000 - PIR1 t
001100011101111101100000010000000000000000100000 - PIR1 a

14 bits are high in the PIR packet, supporting the last bit being a parity bit.

Let’s compare this with the door contacts

001100001100100011000000010100000000000000010000 - DC1 t
001100001101000000010000010100000000000000010001 - DC2 t
001100011101111101100000010000000000000000010000 - PIR1 t
001100011101111101100000010000000000000000100000 - PIR1 a

It now looks like the pre-amble is shorter and the ID a bit more certain.


001100011101111100110000010000000000000000010000 - PIR2 t
001100011101111100110000010000000000000000100000 - PIR2 a

Let’s compare this to the other PIR

001100011101111101100000010000000000000000010000 - PIR1 t
001100011101111100110000010000000000000000010000 - PIR2 t

Wow – only a couple of bits differ. They are almost sequential!


This component is much more complex, so let’s just look at the simplest trigger – the tamper switch.

000010000001000000000000011100000000001000000000 - KP t

Notice how 6 bits are high, and the last bit is 0. It really does look like parity.

Let’s compare with the others:

001100001100100011000000010100000000000000010000 - DC1 t
001100001101000000010000010100000000000000010001 - DC2 t
001100011101111101100000010000000000000000010000 - PIR1 t
001100011101111100110000010000000000000000010000 - PIR2 t
000010000001000000000000011100000000001000000000 - KP t

Now we have a lot more information. The pre-amble has got shorter. Somewhere in the middle it looks like we have data indicating the sensor type.


A typical packet:


We have :

  • Packet start (not shown). The encoded bits 111000 are sent. This is on the short side for a pre-amble.
  • Yellow – this could be a continuation of the pre-amble, which would now be 111000100100 – still really quite short!
  • Red – 18 bits of ID. Not sure which end the other two bits are at. Or are they using the 2 bits of sensor type to make it up to 20 bits?
  • Blue – likely sensor type; 00 – PIR, 01 – door contact, 11 – panel.
  • Purple – status of various switches and alarms.
  • Green – a simple odd-parity checksum bit

I’ve now run out of components to test. We’ve gleaned a fair bit of information about the format of the packet, most importantly that no rolling code is in use.

Where next? I know the format of genuine packets, so I should be able to build a system to transmit these sniffed packets. We’ll test to see if the receiver can pick these packets up. Then we can start modifying the packets bit-by-bit to see how the receiver responds.


Reverse engineering a wireless burglar alarm, part 5

Last time we worked out that data was being transferred from the microprocessor to the CC1150 chip using synchronous serial mode at 6.5kBaud. This time, we are going to look at that data using the logic analyser and try to interpret it.

This is what our data looks like – channel 1 is data, channel 3 is a clock. The Saleae Logic software can help to interpret this as plain synchronous serial.


You might notice that the software doesn’t have an option for synchronous serial – only asynchronous. It does however have “Simple Parallel”. This takes a number of channels and a clock. Serial is just parallel with a single channel, so that is what we will  use.

Another plus of the Saleae software is that you can use multiple analysers against the same channels i.e. on our MISO/GDO1 line we can have an SPI and simple parallel decoder running.

Now we have successfully decoded a series of pulses, and the software has conveniently added little dots to show the data bits:


You might quickly notice that the pulses are either 1, 2 or 3 bits long. Never 4 or more. This is the case along the entire stream of data. 1 and 2 bit pulses are common, and 3 bit pulses are at the beginning, end and at regular intervals. We could guess that 1 bit = 0, 2 bits = 1, and 3 bits signifies the start and end of a packet? Seems sensible to me.

As an aside, it is fairly common for RF systems to encode data so that there are frequent transitions between 1 and 0. This is for a few reasons:

  • To try and keep the average value of the signal midway between 1 and 0, allowing automatic gain controls and DC filters to work correctly.
  • To make sure any clock recovery or synchronisation has frequent edges to work on.
  • Representing 1 bit of data as multiple bits can provide redundancy and error checking.

Manchester encoding is very common, but there are a lot of proprietary and ad-hoc schemes in use. I have seen infrared protocols used on AM OOK systems before now – they kind of meet the requirements and allow the use of existing chips and code.

The entire data burst lasts about 1.20s. At a data rate of 6.5kBaud, that is 7.8k symbols. I don’t fancy manually transcribing or interpreting that much data. There is a high probability that the data repeats to a certain extent, but it can be hard to see the boundaries on a logic trace. Automating this process makes more sense.

Looking back at the data, and my initial observations, I can see:

  • 111 is always followed by 000, and I can see this happens relatively infrequently but regularly
  • 1 is always followed by 00
  • 11 is always followed by 0

So, let’s make some arbitrary choices:

  • 111000 is the start/end of a packet
  • 100 is a 0
  • 110 is a 1

Where to from here then? Python! Let’s read the data in, and try to process it using these simple rules.

Why am I using Python? In recent years I have found it is by far the quickest way to get simple data processing tasks like this done. It seems naturally suited to arrays of data and is tolerant of idiocy. I use Pycharm as a cross-platform IDE – it’s really useful.

I’ve knocked up a very simple program to read in a Saleae logic file, and then interpret the data as above.


It’s getting like a Daily Mail article on hacking in here.

With the input from my trace, I get the following repeating pattern:


No change at all from packet to packet, 48 bits long. This encodes to 150 bits long, and re-transmits about 50 times in the 1.2s burst (retransmission is a common technique to ensure the receiver hears the transmission, even in noisy environments).

We know from the documentation the system uses 20 bit IDs. Just a gut feeling, but I would expect the address to have a lot of entropy, so might assume that the first 20 bits are the address – 001100011101111101 – and the rest is data. There may be a pre-amble and sync word before the ID, meaning it might be shifted a bit further on. To confirm this, I will need to put the sensor into different states (triggered/not triggered,tamper/safe,battery low etc.) and compare to other sensors.

Is the system rolling code? We can’t really say at this stage – we need to grab more traffic. I’d expect the code to roll in 50 retransmits though. It’s not looking good.

What is interesting is that to see this data, I didn’t actually need to look at any RF at all. In fact, I don’t even need the comparatively expensive Saleae Logic – a Bus Pirate acting as a logic analyser would be able to do this.

Where to from here? Let’s start sniffing data from the other door contact and start changing their states. For next time 🙂

Reverse engineering a wireless burglar alarm, part 4

In the last part, we looked at sniffing the SPI traffic between the Elan microprocessor and CC1150 RF chip in a door contact from a Friedland Response alarm system. We worked out which pin was which, and interpreted some of the SPI traffic to check our assumptions were correct.

Part of my general philosophy when reverse engineering products is to just get a good idea of what is going on, rather than rigorously explore each and every avenue. Generally this will give you an overall picture of the system far quicker, and allow you to identify weak points to look at in more detail. So, on the whole, I never have a 100% confidence level in my assumptions.

Let’s look at some other aspects of the sniffed traffic.

First, let’s look right at the beginning of the signals immediately after the sensor is triggered.


We have worked out what channel 0, 3, 4 and 5 do. So what is going on with channel 1? It has an approximate 135kHz clock signal for a short period. Why is this?

Let’s go and look at the datasheet once again. Page 37 – we can see that general purpose I/O pin GDO0 defaults to output a 125-146kHz clock output – the main oscillator frequency over 192. We have a 26MHz crystal, giving us 135.4kHz – exactly as observed.

Why then does it stop suddenly. Maybe one of the registers we set just prior to it turning off – 0x01 or 0x02 – control this pin?

IOCFG0, 0x02, controls GDO0. The lowest 6 bits select what GDO0 should output. What does 0x0C correspond to? Page 38, table 24, shows 0x0C as “Reserved – defined on the transceiver version” – what’s going on here then? Is it a mistake? We’ll come back to this later.

Again, this is something that is really key in reverse engineering – read the datasheets, and read the manuals. They are full of useful information.

Moving further through the SPI packets sent, we get to the end:

Time [s] Packet ID MOSI MISO
0.0041055 28 0x2D 0x0F
0.00417875 28 0x35 0x0F
0.00424825 29 0x2E 0x0F
0.0043215 29 0x09 0x0F
0.00438775 30 0x7E 0x0F
0.004463 30 0x00 0x0F
0.00451425 30 0x0B 0x0F
0.00456675 30 0x25 0x0F
0.0046195 30 0x68 0x0F
0.00467225 30 0x60 0x0F
0.004725 30 0x86 0x0F
0.0047775 30 0xCC 0x0F
0.00483075 30 0xC3 0x0F
0.0049125 31 0x35 0x0F
0.01802275 32 0x36 0x2F

Why is packet 30 so long? 9 bytes instead of 1 or 2 as per the previous strobe commands and register writes.

Address 0x7E doesn’t seem to come up directly in the datasheet. If we refer to Table 28 though, we see that if we want to write to 0x3E in burst mode, we need to add 0x40 onto the address. Burst mode allows us to write multiple values in one go without incrementing the address. 0x3E is the PATABLE or power table, allowing the power of the radio signal to be modulated.


Let’s zoom right back out on the logic trace:


The small white blocks are bursts of SPI traffic as we have looked at already. What about the huge white blocks – let’s zoom in to take a look at them.


That looks like synchronous serial data to me with a clock on channel 3 and data on channel 1. Let’s scroll backwards to examine the SPI transfer immediately prior to this to see how the CC1150 is being configured.

We’ll start from the beginning and manually interpret the commands (I might skip or gloss a few of the really unimportant ones)

  • Strobe command SRES – reset the chip
  • IOCFG1 – GDO1 output pin configuration – set to 0x0B – Set GDO1 to “Serial Clock. Synchronous to the data in synchronous serial mode.
  • IOCFG0 – GDO0 output pin configuration – set to 0x0C – Reserved in the datasheet as it is for the transceiver, CC1101, only. If we look there it means “Serial Synchronous Data Output. Used for synchronous serial mode” So far it looks like these are being setup for some kind of synchronous serial data transfer.
  • SYNC1, SYNC0 – sync word – set to 0xD391. The sync word is a bit pattern that receivers can look out for, in a way people listen out for their name. Oddly, 0xD391 is the default used in the TI software (SmartRF Studio) and code examples. Keeping it as default would likely cause problems in a busy environment (these chips are becoming very common), so this might indicate they are not using the packet control built into the chip.
  • PKTLEN – packet length – set to 0xFF. This is the maximum – 255 packets. It can mean one of three things – fixed packets 255 long, variable length packets up to 255 long, or don’t use the packet control at all. Another sign they might not be using packet control!
  • PKTCTRL0 – Packet automation control – set to 0x12. this is made up of a number of smaller settings:
    • WHITE_DATA – data whitening – set to off.
    • PKT_FORMAT – set to 0b01 –   “Serial Synchronous mode, data in on GDO0“.
    • CRC_EN – enable CRC – set to off.
    • LENGTH_CONFIG – set to 0b10 –  “Infinite packet length packets” – again, bypassing the built in packet control
  • ADDR – address – set to 0x00. This can be used to filter packets down.
  • CHANNR – channel number – set to 0x00. A neat feature of the CC11xx chips is being able to use a number of channels – offsets from the frequency. This can be used for frequency hopping spread spectrum. Not used here though.
  • FREQ2, FREQ1, FREQ0 – frequency control – set to 0x21656a. This equates to 868,299,865kHz. As the channel is set to 0x00, this will be the frequency used.
  • MDMCFG4, MDMCFG3 – modulator configuration, data rate – set to 0x87, 0xF8. This is calculated in a similar way to the frequency using an exponent and mantissa, and gives us 6.24847kBaud. If we look up to MISO/GDO1 in the screenshot above – the clock is showing as 6.25kHz. It’s all starting to come together.
  • MDMCFG2, MDMCFG1, MDMCFG0 – modulator configuration, various. We can see:
    • MOD_FORMAT – modulation – set to 0b000 – 2-FSK.
    • SYNC_MODE – synchronisation mode – set to 0b000 –  “No preamble/sync word”. This means that the system is not using any of the inbuilt packet control. The microprocessor must deal with pre-amble, sync word and so on.
    • NUM_PREAMBLE – number of preamble bytes sent. This is set to 4, but because the SYNC_MODE is set to use no preamble, it is ignored.
    • CHANSPC – channel spacing. If the system was using multiple channels, this decides how far apart they are. This system isn’t so we’ll ignore this.
  • MCSM1, MCSM0 – main radio control state machine config. I’m not going to look in here as it’s unlikely to change how the data is handled.
  • FREND0 – front end TX config. Going to skip this for now.
  • FSCAL4, FSCAL3, FSCAL2, FSCAL1, FSCAL0 – again, RF related and we can skip.
  • FSTEST, PTEST, TEST2, TEST1, TEST0 – various test settings. These are usually defaulted, not explained or shouldn’t be set. Let’s keep it that way.

Immediately after this, the STX strobe command is issued, along with setting IOCFG1 and IOCFG0 again. The SPI stops, GDO0 becomes a clock at 6.5kBaud, and MOSI starts showing data. I don’t know which direction this data and clock are going in, but we can have a good guess.

It looks like the CC1150 is in a mode where it will accept synchronous serial data, generating a clock for the microprocessor to use. Pre-amble, sync, packet length and other features are implemented in the microprocessor. This is an interesting revelation – a huge advantage of the CC11xx chips is the automated packet control, and it has been thrown aside.

Why would this be done? We can only speculate. Asynchronous serial mode is often used by devices when the CC1150 is interfaced to legacy microprocessors – you can just send it raw data and it only does the RF side of things. Ancient 434MHz systems using AM OOK modulation can be changed into narrowband 868MHz products using 2-FSK easily.

Synchronous serial is a bit different – the microprocessor needs to listen to a clock and clock data out. Whilst this is trivial to implement afresh, it doesn’t really fit in with the idea of supporting a legacy application. Maybe Friedland used to use another module that used a similar data exchange.

Decoding an RF packet in a microprocessor isn’t hugely challenging (VirtualWire on the Arduino is a nice example, well implemented), but I have seen numerous systems with quirks and bugs in the packet handling. It’s sometimes even possible to crash receivers using malformed packets.

Now we know how the CC1150 is accepting data – so now we need to try and interpret that data. Next time!

Reverse engineering a wireless burglar alarm, part 3

In part 1, we used some simple tools available to us to look at the modulation and frequency the Response alarms use (868MHz, 2-FSK)

In part 2, we opened the alarm up and looked at the main components in the system (TI CC11xx RF chips with various microprocessors).

Now we are going to try and look at the communication between the microprocessors and the TI CC1150 chips. They have an SPI serial interface, allowing the user to set various registers to control the rich and complex feature set.

I have a number of tools available to me that can sniff SPI. The cheapest is the Bus Pirate. This has an SPI sniffer interface along with a basic logic analyzer. It works well, 90% of the time. If timings are curious or the protocol deviates slightly from normal, it tends to fall over.

I also have an oscilloscope. It is hard work decoding serial though – it doesn’t have any built in protocol analysers.

So I go to my good old friend, the Saleae Logic 8-channel logic analyser. I have had this a number of years and it has rarely let me down. It’s simply brilliant for dealing with embedded systems, and the software is very easy to use and cross-platform.

I’m going to work with the door sensor initially – they are the cheapest and simplest sensors. I was planning on selling unopened sensors, and the PIRs fetch decent prices on ebay (as an aside, the provenance of alarm detectors on eBay is questionable – could this be an attack vector?).

The RF daughterboard has a 8 pin header. We need to work out which is ground, and then we can safely connect the Saleae Logic. We do this using a continuity tester between the battery connector and pins. It looks like pin 1 is ground.


Another pin will be the supply, but at this stage, it doesn’t really matter which. I just need to confirm it is <5V to avoid damaging the logic analyser. I connect the board to the power supply and confirm that no voltages are higher than 3V, regulated down from the two CR2032 batteries.

Small wires are soldered to the pin header to make connecting the logic analyser easier.


We then start the logic analyser with no triggering and press the test button on the contact.


Excellent – this looks very much like we have data!

I could at this stage buzz out the pins to the CC1150 chip to work out what the pins do, but the daughterboard is soldered down so the chip is hard to access. I’d rather just have a guess at the pins – we know it is SPI after all.

SPI requires the following pins:

  • CS – chip select, generally active low.
  • SCLK – the clock for the data.
  • MOSI – master out, slave in data.
  • MISO – master in, slave out data.

CS is nearly always going to be the slowest changing pin – let’s zoom in to the beginning of the trace and see what we have:

Chip Select

From this, I’d wager that CS is channel 0.

Now, to look at this trace, it would be easy to assume that channel 3 is a clock – look how regular it is! However, in SPI, because we are transferring at least 8-bits of data, we need at least 8 transitions each time CS is asserted. Channel 3 isn’t nearly fast enough.

What about channel 4 being the clock? The pulses look to short (and on some traces, they are very irregular as well!):


But if we look a little closer, we can clearly see 8 pulses per CS. There is no requirement for the clock pulses to be regular and they also don’t need to have a 50% duty cycle.

The two other channels with changes are 3 and 5. One will be MOSI, the other MISO – we aren’t really bothered which right now as it won’t have any impact on decoding the data.

I’ll now set up the Saleae Logic’s protocol decoder for SPI on these channels. There are a number of configuration settings, let’s leave them on the defaults and see what happens – it will throw errors or produce obviously squiffy data if incorrect.


The little orange and green boxes represent decoded data – we just need to zoom in to see what that data is now. I can then export this as CSV to examine in an external program. We have no errors, so we can check if the decoding has worked by examining the packets against the datasheet.

Time [s] Packet ID MOSI MISO
0 0 0x30 0xFF
0.0001085 1 0x01 0xFF
0.00018025 1 0x0B 0xFF
0.00024925 2 0x02 0x0F
0.00032075 2 0x0C 0x0F
0.00038925 3 0x03 0x0F
0.0004615 3 0x07 0x0F
0.0005305 4 0x04 0x0F
0.0006025 4 0xD3 0x0F
0.00067225 5 0x05 0x0F
0.00074475 5 0x91 0x0F
0.00081325 6 0x06 0x0F
0.000886 6 0xFF 0x0F
0.00096775 7 0x08 0x0F
0.00103925 7 0x12 0x0F
0.00110775 8 0x09 0x0F
0.00118 8 0x00 0x0F
0.00124725 9 0x0A 0x0F
0.0013195 9 0x00 0x0F
0.001408 10 0x0D 0x0F
0.00148075 10 0x21 0x0F
0.00154925 11 0x0E 0x0F
0.001622 11 0x65 0x0F
0.0016915 12 0x0F 0x0F
0.00176475 12 0x6A 0x0F
0.00183425 13 0x10 0x0F
0.00190625 13 0x87 0x0F
0.00197525 14 0x11 0x0F
0.002048 14 0xF8 0x0F
0.0021175 15 0x12 0x0F
0.00218975 15 0x00 0x0F
0.00225725 16 0x13 0x0F
0.00232975 16 0x22 0x0F
0.00239825 17 0x14 0x0F
0.002471 17 0xF8 0x0F
0.0025405 18 0x15 0x0F
0.00261325 18 0x50 0x0F
0.00269225 19 0x17 0x0F
0.0027655 19 0x30 0x0F
0.002834 20 0x18 0x0F
0.002906 20 0x18 0x0F
0.00306925 21 0x22 0x0F
0.0031415 21 0x15 0x0F
0.0032105 22 0x23 0x0F
0.00328375 22 0xE9 0x0F
0.00335325 23 0x24 0x0F
0.0034255 23 0x2A 0x0F
0.0034945 24 0x25 0x0F
0.00356725 24 0x00 0x0F
0.0036345 25 0x26 0x0F
0.00370725 25 0x1F 0x0F
0.00379825 26 0x29 0x0F
0.003871 26 0x59 0x0F
0.0039405 27 0x2A 0x0F
0.00401325 27 0x7F 0x0F
0.0041055 28 0x2D 0x0F
0.00417875 28 0x35 0x0F
0.00424825 29 0x2E 0x0F
0.0043215 29 0x09 0x0F
0.00438775 30 0x7E 0x0F
0.004463 30 0x00 0x0F
0.00451425 30 0x0B 0x0F
0.00456675 30 0x25 0x0F
0.0046195 30 0x68 0x0F
0.00467225 30 0x60 0x0F
0.004725 30 0x86 0x0F
0.0047775 30 0xCC 0x0F
0.00483075 30 0xC3 0x0F
0.0049125 31 0x35 0x0F
0.01802275 32 0x36 0x2F

This is exactly what I would expect to see when a micro is controlling a CC1150. Let’s work out what is going on.

We are just going to lock at MOSI – the packets the microcontroller is sending to the CC1150.

The first packet is an 1 byte packet, where 0x30 is sent. If we search for 0x30 in the datasheet, we find out that there are a series of 1 byte packets called “strobe commands” on page 42, table 25 . They all trigger changes in the internal state machine. 0x30, SRES, reset – fairly obvious meaning!


Next we have a series of 2 byte packets. You can see the first byte of each packet is generally just incrementing one by one. Again, we look through the datasheet and on page 43, table 26, we have a list of the configuration registers. Notice how we skip some numbers – 0x0C, 0x0D – this is because they are only used for reception, not transmission, and the CC1150 is a transmitter only.

I could go through these one by one, explaining how they are configuring the radio. But let’s just look at the most important ones for now, referring to the datasheet.

FREQ2, FREQ1, FREQ0 are stored in 0x0D, 0x0E, 0x0F and are set to 0x21, 0x65, 0x6A respectively. From page 47 of the data sheet, we need to concatenate these (0x21656a) and then use a simple formula to work out the frequency. This gives a result of 868,299,865Hz – almost exactly as we measured.


MDMCFG2, 0x12, contains modulator settings. Bits 6-4 are the modulation format – so let’s look at them. The value written to 0x12 is 0x00,  so bits 6-4 are 0b000. This corresponds to 2-FSK, as we observed before.

DEVIATN, 0x15, tells us the deviation settings (i.e. how far apart the two frequencies will be in 2-FSK). A simple formula is used. Bits 6-4 give us the exponent, and 2-0 give us the mantissa. 0x15 is set to 0x50, so the exponent is 0b101 and the mantissa 0b000. From this we get 50781.25Hz – again, this corresponds to our ~100kHz gap between the two peaks from part 1.

We are now confident that we the SPI traffic we are looking at is correct. Now we need to work out how data is being sent between the two. There are so many different ways this can be done using the CC1150, so we will need to drill into the settings and sniffed traffic in more detail – which we will do in the next part.

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

  • 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.



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


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



  • 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


  • 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.


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…)


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


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.


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….

Advanced foil impressioning to open high security dimple locks « blackbag

An interesting kit that makes foil impressioning of dimple locks a lot easier – the small pin that is inserted along the length of the key to stop the foil being crushed is a great idea.

By the time this hits the UK, it will cost £250 and the elitist lock smith community will have restricted sales down as far as they can.

Cashless vending FAIL – analysis of a RFID payment system

One other purpose of access cards at work is a cashless payment system for the canteen and vending machines. There are clear advantages – cash requires keeping a float for change, cashing up, auditing, storing etc. There’s also less obvious benefits – in most food outlets staff aren’t allowed to handle cash and food, but this is no longer a problem with a cashless payment system where the card holder simply inserts the card in a reader whilst the member of staff operates a clean till.

Historically these systems have been pretty poor from a security standpoint. At school, a smartcard based system was introduced for school dinners and the tuckshop. The value was stored on the card, and it wasn’t long before one of the PS/2 card readers was liberated and drivers found. The card were simple memory cards, and it only took a few snapshots after making purchases to work out where the value was stored and to modify it. If I remember correctly, there wasn’t even a checksum, though the value was slightly obfuscated. The system was either missing backend auditing or no one was checking it.

That was 10 years ago though, and I would have hoped that the systems in use would have come on a long way. Contactless and contact cards with protected memory and microprocessors are now affordable and in common use in access control systems. For these reasons, it’s unlikely that you’ll find a card where you can just modify the stored value without having access to a private key. Several places I have worked at have such systems, though what I am going to describe here is purely theoretical, of course.

The system consists of ATM like machines for adding value the card – only debit/credit cards allowed, card readers in the shops and canteens, and card readers in all the vending machines.

If we assume that only genuine readers can modify the value on the card, then we need to somehow change the behaviour of one of these readers to our advantage. I’d rather not mess with the ATM like machines, and playing with the readers in front of staff also sounds like a bad idea. The vending machines are nice and hidden away though.

Most modern vending machines have a control board that operates the rotating springs, stores the value of items, operates the display and so on. Then there is some kind of payment module, most commonly a coin handler, sometimes a note handler, and sometimes a card reader. The modular design makes sense – it means you can sell your vending machine worldwide without having to worry about making one that deals in Zimbabwean Dollars as well as Kuwaity Dinar.

If we look at a coin handler, the operation is quite simple:

  1. Insert coins
  2. Value of coins is signalled to control board
  3. User inputs selection
  4. If value of item is lower than coins, vend item
  5. If there is a problem, return coins

The coin return mechanism is simple. The coins are stored on a tray after being inserted. It is tipped one way to put the coins into the collection box, and tipped the other way to return them to the user. There’s no option to give change – it’s all or nothing.

This has important implications – there’s little need for any feedback from the coin handler to the control board. The control board says “return coins”, and the coin handler will do so. There’s no half-way house, no change or incremental payback. There is no need for any feedback from the coin handler to the control board.

Some units give change out. Generally this is a discrete coin hopper that can be instructed to give change. If you put in £1 and the product costs 60p, you should get 40p returned in change. If there is no change left in the hopper, you don’t get any change. Interestingly, you’d normally get this 40p as 2 x 20p coins. If there are no 20p coins left, but there are 10p coins, many machines won’t give you 4 x 10p coins instead. Yet if you bought something for 90p, you would still get a 10p coin returned. I suspect, again, that this is because there is no feedback from the coin hoppers to the control board – they are simply instructed to carry out an action.

So what would this mean if the payment module was swapped for a card reader? It turns out to be quite a lot.

The cards in this system are RFID cards, and the readers in the vending machine are manual insertion/removal type. Inserting the card presses a microswitch, enabling the field and reading the data off the card. I’m not sure why the field isn’t always enabled – I presume that they don’t want to have problems with long range cards being read by mistake.

One the balance is read from the card, any item lower than the value can be bought, and that amount is deducted from the card. This sounds very similar to the coin handler really – although in the example above, rather than say “give out 40p change”, the signal would more likely be “keep 60p”. What happens if the communication between the control board uses the same protocol for both payment modules?

Let’s try pulling out the RFID card just as the machine is starting to vend… nope, the machine debits the card before the vend starts, so I’ve still paid for the item.

So next step – let’s trick the reader. I’ll take my RFID card and slip a business card of the same size below it, and insert the two into the reader. The balance is read, at which point I pull out the RFID card, leaving just the business card which is still depressing the switch. I’d assumed that this attack mechanism would have been covered, but the machine vended the item fine, leaving me with the cash. I can only speculate to the cause:

  1. The control board tells the reader to charge the card
  2. The card reader has successfully read the card previously, and the switch hasn’t changed state, so it must be the same valid card.
  3. The card reader fails to update the balance on the card as a result.
  4. There is no feedback between the reader and control board, so the vend continues

This is completely in line with idea that the communication between the control board and payment module is always the same, regardless of the type. It’s treating it like coins, where the coin handler will always successfully perform the action requested. This highlights another difference between the coin handler and card reader. You relinquish control of the cash with the coin handler, but remain in control of the card with the coin handler.

So, I’ve worked out how to get free stuff from the vending machine. There have to be other ways though.

I’m sure everyone has used a vending machine and the item has hung up on the spring, resulting in the money being lost and you having no Mars Bar. Sometimes a shoulder to the machine sorts it out, but often not. These guys have thought of that though. There is a lightly sprung flap which detects the falling item. This is then used to decide if you should be charged or not.

How can this help me get free stuff? I get my money back if the flap isn’t moved by the falling item. So, if I hold the flap where it is, the item will land on it, and I won’t be charged. All vending machines have a tray which stops you putting your arm up into the product space to steal things, so I can’t just hold the flap up with my hand. But it’s easy enough to form a couple of pieces of wire which will hold the flap up with the tray shut.

This works perfectly – the card isn’t charged and we get the product. Brilliant. Yet it’s still just a free Mars Bar. Let’s take this up a notch.

Let’s think about this a bit more. How exactly does this process work? Here’s one idea:

  1. Read balance.
  2. Ask for product.
  3. Start vending product (if product costs less than the balance).
  4. If vend is successful, charge the card for the product.

There’s a problem here though – the card read is manual insertion/removal. If we remove the card between step 3 and 4, then the card never gets charged! I’ve already tried this though, and it doesn’t work – the card is charged before the vend starts.

So, how else could it work?

  1. Read balance
  2. Ask for the product
  3. Charge the card for the product (if product costs less than the balance).
  4. Start vending product
  5. If vend is unsuccessful, credit the card for the product.

This is much more secure. If we assume that most vends are successful and most people leave the card in the machine until the end, nearly everyone ends up happy. Even when there is an unsuccessful vend and the card is removed, the user loses the cash but the vending machine gains it – which sounds like something a profit making company would go for.

So far, we have two working attacks:

  1. Using a business card to trick the card reader into thinking the card is still there.
  2. Holding up the flap so that although the product is vended we don’t get charged.

What happens if we combine the two?

First, the flap is rigged so that the machine won’t register a successful vend. Next, I insert both cards, let the balance be read, and remove the RFID card. I chose the product, which starts to vend. I re-insert the RFID card, just in time for the machine to decide the vend was unsuccessful. The machine then credits my card for the value of the item. I remove the card and release the item.

Now I have the item and I have been refunded the value of the item. This is brilliant. It’s just a bit of a shame that Mars Bars only cost 40p.

It exposes something about the internal mechanism of the card reader, and again makes me think that the communication is exactly the same as with a coin handler. There are two different ways of signalling the changes to the balance.

One is with increment/decrement signals (in line with the coin handler). This is what would happen in the refund situation:

  1. Read balance – £10.20
  2. Deduct 60p (balance should be £9.60)
  3. Increment 60p (balance should be £10.20)

If we skip step 2, the balance will end up at £10.80 instead!

The other is with absolute values:

  1. Read balance – £10.20
  2. Set balance to £9.60
  3. Set balance to £10.20

If we skip step 2 here, we don’t gain anything!

So, there are a number of serious flaws here.

What could they do to prevent this from happening?

  • Use a motorised card reader – this means that I can’t remove the card when I want.
  • Use a read that detects card presence using the RF field rather than a microswitch – this means I couldn’t remove the card.
  • Send a confirmation signal from the card reader to the control board so the vend can be stopped when something is amiss.
  • Change the balance using absolute rather than increment/decrement signals.
  • Use a breakbeam detector rather than the sprung flap to detect the falling item – this would be much harder to trick.

Of course, backend auditing would quickly catch issues like this. But then, would they bother?

Like I say, all purely theoretical, but is it beyond belief?






Subtle failures in dual purpose ID/access card security

Many of the larger offices, hospitals, universities and schools around London and in other major cities have some form of ID or access control card system. There’s no doubt that these do help improve security. There are however frequently failures either in the designed or realised implementation. I think it is always important to separate the designed implementation from the realised – many systems have been designed to be secure, but factors such as excessive complexity or cost mean that the realised implementation is no longer secure.

Access and ID cards do indeed serve dual purposes:

Identification – this allows someone to verify who you are and to tie you to the card you are carrying.

Access control – the card will either allow or deny you access to the building, based on some form of authorization such as a list of ID cards which are allowed into the building.

By linking you to the card (identification), authenticating the card (which is normally done in the background using some kind of key exchange), and then checking to see if the card is authorized, there is a secure protocol to either allow or deny a person access. I’ve not included “authentication” as one of the purposes as really it is part of both the identification and access control.

A lot of sites don’t use the cards for both purposes however, and this can cause the protocol to break down.

Take a hospital for example, where staff are encouraged to visibly wear ID cards at all times. Many areas of the building will have no enforced access control – the system relies on people being vigilant and questioning anyone with ID. The same system is often used in schools and universities.

There are a number of problems with this system. There is no mechanism to revoke cards short of physical removing them from the holder. It’s also normally trivial to make a visually identical card that will pass all but the closest inspection. The fundamental flaw is that there is no access control in place.

Other sites use the system purely as access control. The card is used as an electronic key. The problem here is that they have some the disadvantages of a key – you have no way of checking that the person using the card is authorized. You can merely check that the card is authorized.

Of course, the most secure option is to use the card for both identification and access control. In fact, it could be perfect, but frequently the implementations have major shortcomings.

One of the big problems is that the two tasks of identification and access control are very different to one another. Humans are excellent at checking to see if a face matches a photo, but are terrible at checking lists of authorized names.

Machines can often be tricked when trying to match a face to a photo, but they excel at checking lists of names.

So often a hybrid solution is used – the human performs the identification and the machine peforms the access control. Sounds ideal, doesn’t it? The common implementation is to have a guard at each door checking the photographs before the holders walk up to electronic access control barriers.

The person checking the face matches the photo doesn’t just have to perform identification – they also need to check that the card is authentic. Authenticating a plastic card takes a lot longer than identifying the person, and frequently this step is skipped, or at best is purely visual. Anyway, why bother – the access control authenticates the card later…

So say I steal someone’s card, stick my photo onto the front, and walk in. The guard identifies me and authenticates the card visually. The barrier then authenticates the card electronically, and authorizes me. I’m in the building when I shouldn’t be.

How do we solve this? If we think about it, putting the photo on the card is a bit of a silly idea. Why not hold it centrally on a database, and allow the guard to both electronically authenticate and visually identify the person at the same time? The reason they don’t do this is because it would massively slow down entry to the building.

There are other issues. We can break the identification step by simply holding the ID card upside down. Humans are awful at matching upside down photos to faces, so this simple trick will often allow you to walk right past guards. You are relying on having a card with someone of the same sex and hair colour, and the guards being relatively polite. This does frequently work.

Commonly the card will give the users other powers as well, and it is possible to exploit these. I have a card for a building that I visit relatively infrequently, and I find that I need to get my card re-enabled each time I visit. I think it expires after a month of not being used.

I entered the building wanting to sign a guest in. I passed the guards, who identified me and let me past. I then went to the reception desk, and asked if I could sign in a guest. They looked at my card, decided it was authentic, but performed no authorization. They issued my guest a pass, and we walked over to the barriers. My guest was allowed through, but I wasn’t – as I expected, my card had expired. The reception desk doesn’t even ask for another form of ID from the guest – they are purely relying on my authorization, which they have implied from my authentic card.

Another interesting situation came up over Christmas. I had to visit a building but didn’t have my card with me. I went to the security desk, knowing that the response would be to call my manager and ask if I could be issued with a day pass. I also knew that on that day, no one would be there to answer the call.

The guard dialled the extension, and I heard it ring a number of times. My mobile started ringing, and I answered it, only to find I was speaking to the guard. What had happened here?

Our phones ring as a group so that if one person is busy, another can answer it. I knew I would be out of the office a lot, so I had set up call forwarding to my mobile. It seems that the entire group of phones was forwarded to my mobile, allowing my manager’s extension to be redirect to me.

The guard had no indication on his phone that the call had been forwarded. It would be possible for a malicious insider to engineer such a situation, allowing an accomplice to enter the building. Luckily, when issuing the day pass, security are presented with both your photo and access rights, foiling this attack. I still think it is worthy of though in other attacks though.