Download as pdf or txt
Download as pdf or txt
You are on page 1of 14

23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

Skip to content

Follow:
RSS
Twitter

Fun Over IP
sendp(Ether()/IP(ttl=32, dst='255.255.255.255')/Fun(\x77\x30\x30\x74\x21));

Home
About
Hacking
Backdoor
Exploits
Metasploit
Network
Password cracking
Radio
Reverse Engineering
Shellcoding
Web

Tags

aes, baudline, cc1111, demodulation, fft, fsk, gnuradio, gqrx, hackrf, reversing, sample, SDR, software defined radio, symbol, verisure, whitening

Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications


by foip on November 16th, 2014

1. Introduction
Verisure is a supplier of wireless home alarms and connected services for the home. A Verisure setup can be composed of multiple devices, sensors and/or detectors such as Motion detectors with camera, Magnetic contacts for doors or Windows, Smoke detectors, Keypads,
Sirens, etc. Each component of the setup communicates using wireless technology with the central gateway called “Vbox”, it-self monitored by Verisure agents through the Internet and/or 3G connection.

As a Verisure customer, I was curious to get a clear view of the design and security measures implemented by the manufacturer. I therefore decided to buy a testing Kit on eBay (120 Euros) to open it and starting an exciting journey inside the boxes.

This post is the first part of my Verisure story and aims to observe radio communications between the multiple devices of the alarm. In other words, we will translate the radio communication into binary messages. Please note that Verisure is the new name of Securitas-
Direct. You may potentially find both names in my scripts and screenshots.

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 1/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

2. Discovering frequency and modulation


We know that 433 MHz and 868 MHz are popular bands for such equipments. Starting our favorite spectrum analyzer (GQRX in this case) confirmed our thoughts by showing some strong pulses while we were pushing random keys on the keypad alarm, located next to the
HackRF.

In order to get a clear view of the signal, samples were recorded using hackrf_transfer tool and then opened into baudline:

1 $ hackrf_transfer -s 2000000 -f 869000000 -a 0 -r /tmp/hackrf_verisure_s2000000_f869000000_01.iq


2 call hackrf_sample_rate_set(2000000 Hz/2.000 MHz)
3 call hackrf_baseband_filter_bandwidth_set(1750000 Hz/1.750 MHz)
4 call hackrf_set_freq(869000000 Hz/869.000 MHz)
5 call hackrf_set_amp_enable(0)
6 Stop with Ctrl-C
7 3.9 MiB / 1.000 sec = 3.9 MiB/second
8 3.9 MiB / 1.000 sec = 3.9 MiB/second
9 3.9 MiB / 1.000 sec = 3.9 MiB/second
10 4.2 MiB / 1.000 sec = 4.2 MiB/second
11 3.9 MiB / 1.000 sec = 3.9 MiB/second
12 3.9 MiB / 1.000 sec = 3.9 MiB/second
13 3.9 MiB / 1.000 sec = 3.9 MiB/second
14 4.2 MiB / 1.000 sec = 4.2 MiB/second
15 ^CCaught signal 2
16 2.1 MiB / 0.540 sec = 3.9 MiB/second
17
18 User cancel, exiting...
19 Total time: 8.54128 s
20 hackrf_stop_rx() done
21 hackrf_close() done
22 hackrf_exit() done
23 fclose(fd) done
24 exit

Nice! Zooming into the signal shows 2 spikes which means that we are probably in front of a 2-FSK modulated signal.

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 2/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

3. Chipsets and datasheets


Before going further, it could be interesting to learn a bit more about the micro-controller used by the devices. As you will see, this information is really helpful since it gives us some clues about the potential modulation, ciphering, data encoding, etc. Opening a magnetic contact
revealed a CC1110-F16 chip.

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 3/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

Briefly, the datasheet informs us about the following capabilities of the chip:

Modulation: 2-FSK, GFSK, MSK, ASK, and OOK


128-bit AES supported in hardware coprocessor (so if data looks encrypted, we probably already know which cipher suite is in use)
8051 MCU architecture (needed later for IDA Pro)
Optional automatic whitening and de-whitening of data.

Additionally, we know a magical firmware called RFCat which can definitively help us to learn and play with CC1110 chips. RFCat will be largely used in the next parts of our Verisure story. For now, we will focus on GNURadio framework and the HackRF One SDR platform.

4. GNURadio at works
41. A First FFT
Let’s build a simple GNURadio flowgraph using the HackRF as a source, plus an FFT Sink. To avoid DC spike in the middle of our signal, we tune the HackRF to 520KHz below the interesting frequency, and then shift back the signal using the Frequency Xlating FIR Filter
block. A few GUI sliders are used to control the gain and to provide additional fine-tuning of the frequency.

Great. Our supposed 2-FSK modulated signal is back. The center frequency is about 869.036 MHz.

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 4/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

4.2. Signal filtering and demodulation


It is time to start demodulating the signal but first, we need to remove any unwanted noise or adjacent communications.

4.2.1. Filtering
Using baudline, we have observed about 38.3 KHz between the MARK and SPACE frequencies, so a deviation of about 19 KHz.

In our GNURadio flowgraph, we then apply a Lowpass filter against our signal using a cutoff value of 21 KHz (so a bit more than 19 KHz) and a transition width of 15 KHz:

1 firdes.low_pass(1,samp_rate, 21000, 15000)

4.2.2. Demodulation

As we are facing a potential FSK modulated signal, a new Quadrature Demod block is added to the flowgraph, which will then send the demodulated signal into a WAV file for further analyze. The new flowgraph becomes:

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 5/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

Haaaa, by opening our WAV file using Audacity (or any other WAV file editor), the demodulated signal seems to reveal its secrets: a preamble (0101010101…) and a potential synchronization pattern.

Let’s go a bit further by slicing the signal into propers 0 and 1. The Binary Slicer block aims to convert all samples above 0 to 1, and sample below 0 to 0. The block is inserted between the demodulator block and the WAV sink.

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 6/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

Back to Audacity, this beautiful binary sequence appears…

4.3. Getting sync-word (Access Code)


Getting the synchronization word is now only a matter of observing the pattern just after the preamble. Audacity helps to do this by adding a Label layer on top of the WAV signal. The difficulty here is to find the right police character which match (more or less) the flow of our
signal. We observe a double SyncWord equal to 0xD391.

4.4. Getting symbol rate and samples per symbol


So far so good. The next step is to discover the symbol rate and the samples per symbol needed to convert this signal into a binary sequence (done by the “Clock Recovery” block).

4.4.1. Symbol rate

What is “Symbol Rate” ? By symbol, we mean 0 or 1. Thus the question to answer is “How many 0 or 1 do we observe per second?”. I know that better techniques exist to compute this value (I just need to learn them) but right now, I will simply count the number of symbols
from the Audacity view:

We count about 69 symbols during 0.00180 seconds, which give a symbol rate of 38333

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 7/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP
1 $ echo -n "010101010101010101010101011010011100100011101001110010001111100001111" | wc -c
2 69
3
4 $ bc
5 bc 1.06.95
6 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
7 This is free software with ABSOLUTELY NO WARRANTY.
8 For details type `warranty'.
9 69 / 0.00180
10 38333
11 quit

As I said, this method is probably not the most accurate. Actually, I found a more precise value by performing the same exercise on a lager portion of the signal (but making screenshots less clear). The final symbol rate is 38450.

4.4.2. Samples per symbol


The number of samples per symbol is one of the most important value needed by the Clock Recovery block. Remember that your SDR device is configured to receive or transmit signal at a specified sample rate. The number of samples per symbol is just the number of
samples needed to send one symbol (0 or 1), and is simply computed like this:

1 samples_per_symbol = sample_rate / symbol_rate

We now have everything we need to setup the Clock Recovery block:

4.5. Decoding packets


The remaining steps to get digital messages are to recognize the frames using the syncword (done by the Correlate Access Code block) and to decode them (done by the Packet Decoder block). There are a couple of GNURadio blocks dedicated to decoding/encoding packets
but since we are dealing with CC1110 devices, we had to create specific blocks able to respect the CC1110 packets format. Further information about these blocks can be found on the following blog post: GNU Radio – CC1111 packets encoder/decoder blocks.

The final GNURadio flowgraph is:

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 8/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

As you can see, the Packet Decoder (CC1111) block receives a python queue as argument (see Target Message Queue). This is where our decoded messages will be sent out.

This flowgraph will actually not be executed as it. Another python script will managed its execution and will pull messages from the python queue, dissect them (as Wireshark would do against a pcap file) and print them out on the screen.

Here below is the main script.

1 #!/usr/bin/env python
2 #=============================================================
3 # Securitas-Direct (Verisure) RF sniffer
4 # By Jerome Nokin (https://funoverip.net / @funoverip)
5 #=============================================================
6 #
7 # Usage: securitas_rx.py [-k KEY]
8 #
9 # optional arguments:
10 # -k,--key <KEY> Optional AES-128 Key (hexadecimal)
11 #
12 #=============================================================
13
14 import ctypes
15 import sys
16 import datetime
17 import argparse
18 from grc.verisure_demod import verisure_demod
19 from threading import Thread
20 from Crypto.Cipher import AES
21 from binascii import hexlify, unhexlify
22 from time import sleep
23
24 # Colors
25 def pink(t): return '\033[95m' + t + '\033[0m'
26 def blue(t): return '\033[94m' + t + '\033[0m'
27 def yellow(t): return '\033[93m' + t + '\033[0m'
28 def green(t): return '\033[92m' + t + '\033[0m'
29 def red(t): return '\033[91m' + t + '\033[0m'
30
31 # Thread dedicated to GNU Radio flowgraph
32 class flowgraph_thread(Thread):
33 def __init__(self, flowgraph):
34 Thread.__init__(self)
35 self.setDaemon(1)
36 self._flowgraph = flowgraph
37
38 def run(self):
39 self._flowgraph.Run()
40 #print "FFT Closed/Killed"
41
https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 9/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP
42 # AES decryption
43 BS = 16
44 pad = lambda s : s + (BS - len(s) % BS) * chr(BS - len(s) % BS)
45 unpad = lambda s : s[0:-ord(s[-1])]
46 def aes_decrypt(ciphertext, iv, key, padding=True):
47
48 cipher = AES.new(key, AES.MODE_CBC, iv)
49 plaintext = cipher.decrypt(ciphertext)
50 if padding:
51 return unpad(plaintext)
52 else:
53 return plaintext
54
55 # Generate timestamp
56 def get_time():
57 current_time = datetime.datetime.now().time()
58 return current_time.isoformat()
59
60 # Print out frames to stdout
61 def dump_frame(frame, aes_iv = None, aes_key = None):
62
63 # Dissecting frame
64 pkt_len = hexlify(frame[0:1])
65 unkn1 = hexlify(frame[1:2])
66 seqnr = hexlify(frame[2:3])
67 src_id = hexlify(frame[3:7])
68 dst_id = hexlify(frame[7:11])
69 data = ""
70
71 # Payload is a block of 16b and AES key provided ? Try to decrypt it
72 if (ord(unhexlify(pkt_len))-2-8) % 16 == 0 and aes_iv!=None and aes_key!=None:
73 if unkn1 == '\x04':
74 # block is 16b without additional padding
75 data = " ".join(hexlify(n) for n in aes_decrypt(frame[11:], aes_iv, aes_key, False))
76 else:
77 # block is 16b with padding
78 data = " ".join(hexlify(n) for n in aes_decrypt(frame[11:], aes_iv, aes_key))
79 if len(data) ==0:
80 data = "<empty> Wrong EAS key ?"
81 else:
82 data = " ".join(hexlify(n) for n in frame[11:])
83
84 # Print out the frame
85 print "[%s] %s %s %s %s %s %s" % (get_time(), yellow(pkt_len), blue(unkn1), seqnr, green(src_id), red(dst_id), pink(data))
86
87 # Main entry point
88 if __name__ == '__main__':
89
90 aes_iv = unhexlify("00000000000000000000000000000000")
91 aes_key = None
92
93 if sys.platform.startswith('linux'):
94 try:
95 x11 = ctypes.cdll.LoadLibrary('libX11.so')
96 x11.XInitThreads()
97 except:
98 print "Warning: failed to XInitThreads()"
99
100 # Read args
101 parser = argparse.ArgumentParser()
102 parser.add_argument("-k", "--key", help="Optional AES-128 Key (hex)", type=str)
103 args = parser.parse_args()
104
105 # Initializing GNU Radio flowgraph
106 flowgraph = verisure_demod()
107
108 if args.key:
109 print "[%s] AES key provided. Decryption enabled" % get_time()
110 aes_key = args.key
111 aes_key = ''.join(aes_key.split())
112 aes_key = unhexlify(aes_key)
113 print "[%s] AES-128 IV : %s" % (get_time(), hexlify(aes_iv))

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 10/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP
114 print "[%s] AES-128 key: %s" % (get_time(), hexlify(aes_key))
115
116 # current frequency
117 freq = 0
118
119 # Some additional output
120 print "[%s] Starting flowgraph" % get_time()
121
122 # Start flowgraph insie a new thread
123 flowgraph_t = flowgraph_thread(flowgraph)
124 flowgraph_t.start()
125
126 # Until flowgraph thread is running (and we hope 'producing')
127 while flowgraph_t.isAlive():
128 # Did we change frequency ?
129 if freq != flowgraph.get_frequency():
130 print "[%s] Frequency tuned to: %0.2f KHz" % (get_time(), flowgraph.get_frequency()/1000)
131 freq = flowgraph.get_frequency()
132
133 # Emptying message queue
134 while True:
135 if flowgraph.myqueue.count() <= 0:
136 break;
137 frame = flowgraph.myqueue.delete_head_nowait().to_string()
138 dump_frame(frame, aes_iv, aes_key)
139
140 # I can't exit the script because of a blocking call to "myqueue.delete_head()". So for now..
141 sleep(0.1)
142
143 print "[%s] Exiting" % (get_time())
144
145 # vim: tabstop=8 expandtab shiftwidth=4 softtabstop=4

Here is the final output:

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 11/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP

A few comments about the output. Briefly:

In yellow: the length of the packet


In blue: still unclear but it appears to be related to payload encryption (encrypted or not, has padding or not, …)
In grey (and gray): a kind of sequence number
In green: the source ID of the packet
In red: the destination ID of the packet
In pink: the payload

5. Final note
The reader has probably observed from the output of the script that an AES-128 key is provided and that payloads are decrypted. The way we recovered the key will be discussed later on at the following address. Don’t try this key at home since keys are randomly generated by
the VBox.

GNURadio flowgraph and python script can be downloaded from https://github.com/funoverip/verisure-alarm.

Prerequisite:

I’ve used HackRF One as SDR platform but any other SDR device should make the trick.
You will need GNURadio 3.7 or above
Do not forget to also install the GNURadio gr-cc1111 blocks !

Last but not least, a big thank you to Michael Ossmann for his awesome SDR class. Strongly recommended!

Hope you enjoyed this post…

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 12/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP
Regards.

(55 votes, average: 4.82 out of 5)

© 2014 – 2015, Fun Over IP. All rights reserved.

From → Hacking, Radio, Reverse Engineering

One Comment

1. Thierry permalink

Very interesting… I’ve a question not about the protocol, but more about the communication… A vendor tell me that is a “ping back” on two separate canal to avoid wireless network jamming and limit possible sabotage…

did you seen something like that (ping back or second (backup) canal ?)

regards,
Thierry

Comments are closed.

Looking for an Ethical Hacker ?


I am also working as freelancer! Please visit my company website: https://www.jnxsecurity.com .

Latest Posts
McAfee SiteList.xml password decryption
Reverse Engineer a Verisure Wireless Alarm part 2 – Firmwares and crypto keys
Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications
GNU Radio – CC1111 packets encoder/decoder blocks
Exploit: McAfee ePolicy 0wner (ePowner) v0.1 – Release
Symantec Endpoint Protection Manager – CVE-2013-1612 – Remote Buffer Overflow – PoC
Turning your Antivirus into my botnet – OWASP Benelux 2013 – Slides
WatchGuard – CVE-2013-6021 – Stack Based Buffer Overflow Exploit
Cracking WatchGuard passwords
Exploit: McAfee ePolicy 0wner (ePowner) – Preview

Archives
February 2016 (1)
December 2014 (1)
November 2014 (1)
July 2014 (1)
April 2014 (2)
December 2013 (1)
October 2013 (1)
September 2013 (1)
June 2013 (1)
October 2012 (2)
July 2012 (2)
June 2012 (1)
February 2012 (1)
September 2011 (1)
April 2011 (1)
March 2011 (1)
January 2011 (1)
December 2010 (4)
November 2010 (1)
Search

About
These are small Tips & Trik that could be useful to you, or not.
These materials are for educational and research purposes only. Any actions and or activities related to the material contained within this Website is solely your responsibility.

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 13/14
23/05/2020 Reverse Engineer a Verisure Wireless Alarm part 1 – Radio Communications | Fun Over IP
Categories
Backdoor
Exploits
Hacking
Metasploit
Network
Password cracking
Radio
Reverse Engineering
Shellcoding
Web

Search
Search

Copyright © 2020 Your Name Here. Titan Theme by The Theme Foundry.

© 2010-2020 Fun Over IP All Rights Reserved -- Copyright notice by Blog Copyright

https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/ 14/14

You might also like