Making of Compass bIOTech v1.0

The “Internet of Things” (IoT) grows quickly. More and more devices are connected to the Internet to automate tasks and simply life. Fridges automatically order milk, cars are taught to self-drive via a simple update and bridges send live updates about their structural integrity.

According to Gartner’s 2016 Tech Trends, IoT will define the shape of tomorrow’s business. At Compass, we also appreciate the impact of connected devices in the near future, in terms of how they can make our lives easier, and how they can make our information more exposed. With this in mind, we recently opened a new security training on the basics of IoT and their vulnerabilities.

Compass bIOTech v1.0 is our own piece of Hardware in the grand IoT puzzle of devices. This smart device has been designed to measure the moisture level of plant pots using a capacitive sensor. It then connects to the cloud (Hacking-Lab) and an e-mail alert can be sent in case of low humidity level.

But before it reached its v1.0 state, the Compass bIOTech sensor went through multiple stages of development between an original idea and its realisation:

1 – Idea

To give a little life to your office, or to make your living room livelier, green stuff is always a nice addition to your everyday environment. Problem: these things need attention! We all at some point forgot to water a plant, and came back after a day, a weekend, or a longer holiday to find it dried out.


The plant of Ivano, at Compass Office Bern

At Compass, we decided to tackle this problem and to grow ourselves a green thumb, green like a circuit board! With no time to spare, Reto Schädler started the design, with a few necessary features in mind:

  1. one must be able to configure the device’s humidity threshold,
  2. a status should be readable directly on the device,
  3. the thing must communicate with a cloud,
  4. the battery should last long.

2 – Circuit Board Design

Schema Compass bIOTech v1.0

Schema Compass bIOTech v1.0

The capacitive humidity sensor consists of a circuit path that is charged via the resistor R5. Using this, we can measured how long it takes until the voltage is half of the operating voltage.

The 32bit ESP8266 Microcontroller Chip is based on the Arduino development environment and has built in Wifi capabilities. It requires an operating voltage of 3.0 – 3.6 Volt and runs at 80MHz.

Since the two AA-Batteries have a voltage level at max. 3V, a Step-Up Convert to 3.3V is necessary. And because of the required battery life time, a Wake-Up chip is used to cut power supply via MOSFET.

Versuchsaufbau Compass bIOTech v1.0

Prototype Compass bIOTech v1.0

3 – Realisation


Left: PCBA 3D Altium Designer, Right: Compass bIOTech v1.0 PCBA

In configuration mode, the chip serves as a Wifi AP and provides DHCP to connecting devices and a web GUI for configuration purposes. In measurement mode, the device connects to the configured SSID/password and submitts moisture level, battery level and firmware version to a dedicated Hacking-Lab services.


4 – Where to get your own bIOTech device

We will be giving away a first bunch of bIOTech devices at Swiss Cyber Storm on October 19th in Lucern. Visit the conference and walk by our both. We will be glad to equip you with your own green thumb.

For those who can’t make it to the conference, stay tuned and sign-up for our next IoT security training where we will tinker with the devices interfaces and security issues.

 Grab’em while they’re hot!

Software Defined Radio (SDR) and Decoding On-off Keying (OOK)

This post will give a quick intro into software defined radio (SDR) basics and provide guidance for the decoding of a very simple form of digital modulation (on-off keying).

Device Wireless Specs

Wireless junk hacking is not too difficult. Usually, devices transceive in the 433MHz or 868MHz ISM radio bands. As these bands are somewhat lax with licensing all devices operating in these bands must be capable of tolerating interferences of other band users. Pretty much comparable to the Internet 🙂 The European communications office (ECO) maintains a list of bands for European countries, including Switzerland. The list provides information allocated ranges and its specific purpose e.g. 5000MHz to 5030MHz is reserved to the GALILEO global navigation satellite system (GNSS) project.The US make it even simpler to get up to speed with any junk’s wireless configuration (frequency, modulation types and line coding). Every wireless device approved for the US market must carry an FCC ID. The online catalog provides access to the wireless specs of the devices based on its ID (usually printed on the device’s back or specification sticker).

Radio Observation

Alexandru Csete’s gqrx software defined radio comes in as a handy spectrum analyzer when looking for exact frequencies. It’s mainly based on the GNU radio project and supports all well-known platforms (Ettus USRPs, BladeRF, HackRF, RTL chipset et. al).

For the devices I have at hand (light switches, temperature and humidity sensors, car keys, M-Bus transmitters) it worked out they all operate in the 433MHz and 868MHz bands and can be easily observed with gqrx.


The spectrum analyzer (mouse tooltip) tells us that the specific light switch is operating at 433.93 MHz. An interestingly enough gqrx supports other fun and geek stuff such as listening to FM radio or eavesdrop on road work and building site radio conversations.

Signal Capturing

Well, signal capturing slightly varies depending on the device and library you use. The device I used for this tutorial is originally an DVB-T USB stick but comes with the relevant Realtek RTL2832 chipset and goes for a few bucks on most major reseller platforms. Check the supported hardware list at the gnuradio site. Hat tip to the Defcon Switzerland folks who provided me with one for cheap.

The following lines give an idea on how to capture signals with the Realtek chipset family of devices.

bla@bli:~$ rtl_sdr -f 433850000 -s 1000000 -g 20 switch.cu8
 Found 1 device(s):
 0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
 Found Rafael Micro R820T tuner
 Exact sample rate is: 1000000.026491 Hz
 [R82XX] PLL not locked!
 Sampling at 1000000 S/s.
 Tuned to 433850000 Hz.
 Tuner gain set to 19.70 dB.
 Reading samples in async mode...
 ^CSignal caught, exiting!

User cancel, exiting...

Make sure not to capture at the exact determined frequency of the device but rather slightly above or below as the internal synthesizer will otherwise interfere and overlay the signal. Note, that we chose to sample the signal at a rate of 1 million samples per second (1 Msps) and the output I/Q data was stored in the cu8 format. Some tools create outputs as complex signed int (.cs8, HackRF), others as complex unsignend int (.cu8, RTL) and GNU radio prefers complex float format (.cfile). There is a GNU Radio Companion (GRC) template and Paul Brewer’s rtlsdr-to-gqrx tool for conversion from .cu8 to .cfiles, should one need to pivot between the file types.

Alternatively one could use gqrx and record or replay signals in cfile format (Menu bar => Tools => I/Q recorder, CTRL-I). Note: Replay doesn’t transmit your signal but displays your capture within gqrx.

Signal Inspection

I used inspectrum to inspect my capture files. Once loaded, the capture coloring needs some tweaking but usually gives good hints on simple modulation, codings (e.g. Manchester) and the signal’s symbol rate.


Usually, slight zoom and adjustment of power max an min sliders allows to easily discover the on-off keying modulation used in the example. Set the correct sample rate and drag the grid over the signal in order to determine the symbol rate of the signal.


The symbol rate of the switch signal is 1631 Hz. Scrolling through the capture will also reveal that the on and off signal of the switch only differ in few locations, share the same bit heading and are being sent multiple times in a sequence. Pressing the button once obviously results in three or more transmissions of the on or off signal.

Signal Decoding

The GRC is the tool of choice for simple digital signal processing. It provides a building block GUI that allows for quick design of processing flows. The following design serves as a quick and dirty approach for OOK demodulation.


The relevant variables for the decoding are the sample rate (samp_rate: 1 Msps) and the symbol rate (baud_rate: 1631 Hz) which must be set to the values determined before.

The file source points to .cfile version of the previously captured signals and feeds data into a throttle block to avoid infinite processing speed. The “Complex to Mag^2” and “Threshold” blocks will convert the signal wave forms into a rectangular pulse of ones and zeros. Note, that the data type switched from complex (light blue) to float (orange) with the “Complex to Mag^2” block.

The “Keep 1 in N” block will assure the one bit is represented by a single data point. N is computed as samp_rate/baud_rate. Note, such rough way of signal processing may not work with signals that slightly vary the baud rate or with long lasting sequences. Even with short signals one must expect small errors. The scope sink then displays the decoded binary values.


Compare the scope plot to the previous inspectrum screenshot and you will notice that the demodulated signal actually compares with the figure in inspectrum.

Signal Analysis

GRC Visualization Support

None of the visual sinks in GRC provide easy means to visualize binary streams and adjustments to easily spot patterns and variations between streams. Thus, I decided to come up with a custom out-of-tree module for binary visualization and inspection, in short BinViz.

The initial GRC project requires small justifications to feed data into BinViz instead of the WX GUI Scope.


The “Float to Char” block will convert float values into 0x00 and 0x01. Moreover, the “Unpacked to Packed” block will squeeze eight chars into a single byte (e.g. 0x00 0x00 0x00 0x01 0x01 0x01 0x01 0x01 => 0x1F) and feed this into BinViz.

BinViz Configuration

Parameters start, end and drop patterns allow for justification of how streams are displayed and aligned. These parameters take strings composed of 0s and 1s e.g. 01010101 as a preamble or start pattern. The display will start on a new line for each occurrence of the start pattern. On detection of the end pattern the display will wrap to a new line. In case both, the start and end pattern are defined, the display will drop any out-of-bounds bits and only display streams from start to end on a single line each. Once the start pattern is being detected additional occurrences of the pattern will be ignored until the end is detected.

To get rid of long sequences of zero bytes or arbitrary unwanted bit sequences set “skip zero bytes” to true or define a string of 0s and 1s for the drop pattern to be removed. Note, the drop pattern and “skip zero bytes” have precedence over start and end detection patterns.


The display itself allows for some semi-live adjustments and manual analysis. E.g. the mouse wheel on the display allows to zoom-in and zoom-out while new bits are being displayed instantly. Once the display is clicked it will stop painting new bits and display a cursor and its x/y-position. In that mode, one could easily count bits or select part of the bitstream for magnification and closer inspection.

Visual Signal Analysis

Earlier analysis using inspectrum lets us observe six occurrences of the on signal when switching on and further six occurrences of the off signal when switching off. For this type of wireless junk it is probably irrelevant how many times the receiver picks up the signal. As noted earlier it is rather a matter of resilience towards other ISM band users to send the signal multiple times. Just to make sure its being picked up, sooner or later.


BinViz was configured “11010011” for the start and “1001001001001001001” for the end pattern. That way, only relevant data is displayed. Thanks to BinViz capabilities the six on and off signals are easily recognizable as single rows. Moreover, the the differences between the on and off signals is immediately clear.

Looking forward for you contributions

Hands-on, IoT Security Training

If you need more hands-on with junk hacking or analysis of IoT devices then you are very welcome to join us for our brand new practise oriented training on “IoT Security” held in German at the Compass head office in Jona on September 20th/21st 2016. Sign-up here.

Netzwerktraffic und APT Analyse

Compass Security wird vermehrt von Kunden bzgl. Verdacht auf Advanced Persistent Threat (APT) kontaktiert. Unter die Bezeichnung “APT” fallen komplexe, zielgerichtete und äusserst effektive Angriffe auf kritische und zuweilen gar unternehmenswichtige Computersysteme bzw. deren gespeicherte Informationen.
Die Analyse von potentiell infiltrierten Netzen und Systemen gestaltet sich jedoch als enorm aufwändig, da Unmengen von Datensätzen und Logs ausgewertet werden müssen. Compass hat deshalb immer wieder verschiedene Aspekte im Bereich APT, Forensik und Incident Response beleuchtet. Einerseits betreiben wir Research mit internen “Hack Labs” und “Research Weeks”, wo unsere Spezialisten sich mit den neusten Erkenntnissen der Scene auseinandersetzen bzw. diese weiter treiben und andererseits bearbeitet Compass in Zusammenarbeit mit den Security Fachabteilungen einer Vielzahl von Hochschulen, entsprechende Themen.

Eine entsprechend gewürdigte Maturaarbeit aus dem letzten Sommer möchten wir der Öffentlichkeit nicht länger vorenthalten und publizieren darum die Resultate im Rahmen dieses Posts. Im Mittelpunkt des Whitepapers steht die Analyse von APT mittels Splunk, einer spezialisierten Software zur Analyse von grossen Mengen maschinengenerierter Logdaten. Es werden darin auch alternative Wege zur Auswertung eruiert und ein Standardvorgehen für APT Fälle vorgeschlagen. Das Paper greift auch das bei Compass übliche Vorgehen bei forensischen Analysen auf und gibt dem technischen Leser in gewohnter Compass manier, viele technische Details mit auf den Weg. Natürlich auch einige Ideen, wie man das Logging von bestimmten Diensten optimieren könnte.

Möchten Sie gerne mehr zum Thema wissen? Möchten Sie auch erfahren, was dies in der Praxis bedeutet? Dann können wir Ihnen unser nächstes “Hands-on Seminar” mit dem Titel: Network Analysis & Advanced Persistent Threats vom 25. und 26. August 2015 in Bern empfehlen.

In der Zwischenzeit wünschen wir Ihnen viel Spass beim Schmökern. Behalten Sie einen kühlen Kopf compass_security_schweiz_whitepaper_apt_network_analysis_w_splunk_v1.1.pdf.

Compass Security Crew,
Cyrill Brunschwiler

IPv6 Secure Neighbor Discovery (SeND)

Finally, IPv6 is arriving… Since the IPv6 Launch Day in 2012, the number of native IPv6 users have been sextupled. In Switzerland, the IPv6 adoption rate is around 10%, which is quite impressive. In this blog post, the successor of ARP, namely the Neighbor Discovery Protocol (NDP), is introduced and its security features described. IPv4 ARP attacks are well known and documented. Similar attack vectors exist for IPv6’s NDP. To overcome these limitations, the IPv6 SeND (Secure Neighbor Discovery) was introduced back in 2005.

NDP is responsible for:

  • finding other nodes on the same network
  • providing the needed IPv6 prefix exchange mechanism
  • allowing IPv6 address auto-configurationand therefore enabling some IPv6 specific features like DAD (duplicate address detection)

NDP’s main messages are the advertisement and solicitation packets for either the router or the neighbor (host). Common attacks are spoofing (also used in IPv4, known as ARP spoofing), flooding router advertisements or denial-of-service. When a host creates his auto-generated IPv6 address, all other nodes on the same link are asked if this address is already taken. A malicious network participant could always claim he already uses this address for which a request was just sent, creating a denial-of-service condition.

SeND uses cryptographically generated addresses (CGA) based on private/public key pairs to generate IPv6 addresses. A recipient of such an IPv6 packet can verify the authenticity of the IPv6 address with the provided public key. Furthermore, SeND uses a router authorization process to identify valid router advertisements (IPv6 prefixes among other things) based on a trust anchor (e.g. a certificate authority).

Due to the design of IPv6 SeND, DoS attacks are possible because of its computational costs. Furthermore, it only makes sense to use IPv6 SeND in pure IPv6 networks. Privacy issues also exist, because the public key doesn’t change and is sent with every IPv6 SeND packet, regardless of the currently connected network.

Most vendors do not natively implement SeND in their products (e.g. Google’s Android, Apple’s IOS, *nix, Windows) for the moment. Cisco’s IOS 12.4-24(T) and Juniper JUNOS version 9.3 onwards ship with a SeND implementation. On the operating system side, experimental implementations exist for Linux and Windows. Due to this sparse support (and the requirement of running exclusively IPv6), SeND cannot be used today to secure larger environments down to the workstation or server. But SeND can be an option to secure your inter-router traffic provided your network equipment supports it.

Further details can be found in the following presentation: IPv6 Secure Neighbor Discovery.

Thanks to Mateusz Khalil and Alexandre Herzog for the review and comments for this post.


  • RFC3971: Secure Neighbor Discovery (SEND)
  • RFC3972: Cryptographically Generated Addresses (CGAs)
  • Ed Horley IPv6 Bootcamp presentation, 2014
  •, «IPv6 Secure Neighbor Discovery», 2012
  • «IPv6 Security», Eric Vyncke, Cisco, 2014
  • Short summary of SeND, “IPv6 Secure Neighbor Discovery”, EPFL, Claire Musso, Syrine Boujnah, Khalil Hajji, Dec 2013