I started (but didn’t really finish…) a series of posts reverse engineering several parts of a Friedland wireless burglar alarm. I will come back to finish it off, but in order, here are the posts:

• Reverse engineering a wireless burglar alarm, part 1 – spectrum analysis and basic signal capture with SDR
• Reverse engineering a wireless burglar alarm, part 2 – breakdown of components and major circuit details
• Reverse engineering a wireless burglar alarm, part 3 – sniffing SPI data between the microcontroller and CC1150 transceiver using the Saleae Logic
• Reverse engineering a wireless burglar alarm, part 4 – manually decoding some of the SPI traffic using the CC1150 data sheet
• Reverse engineering a wireless burglar alarm, part 5 – working out the data encoding between devices in the alarm system
• Reverse engineering a wireless burglar alarm, part 6 – working out what the individual bits in the data between the devices mean
• Reverse engineering a wireless burglar alarm, part 7 – setting up the hardware to replay the signal from a device
• Reverse engineering a wireless burglar alarm, part 8 – writing software to replay the signal from a device

If anyone wants any further details about technologies used in alarm systems (though not this one), I have another series of posts:

• Keep rolling, rolling, rolling – rolling codes and issues commonly found
• It swings both ways, especially for RF comms – why bi-directional RF systems are much better
• Encryption is only part of the solution – products often use encryption as a buzzword, but fail by still allowing replay attacks and using fixed keys
• The ups and downs and ins and outs of spread spectrum – how systems use frequency hopping spread spectrum, and why it isn’t a great security feature
• Security devices and product differentiation – why it seems dishonest to differentiate by weakening encryption.