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.

Embedded devices and cell phone flash memory acquisition using JTAG

Back in Black (back from Black Hat with a bag full of schwag and branded black shirts). 

Black Hat and DEF CON again allowed insights into latest research and concerns. Where some topics loose grip ( vulnerability scanning, IPv4, DNS, general web issues) others gain momentum (DDoS, mobile computing, smart energy, industrial control and embedded systems). Myself was speaking on the advanced metering infrastructure and specifically on the security of the wireless M-Bus protocol. Slide deck and whitepaper are available for download from the Compass Security news page[1].

At that time, I would like to let you know about a little invention that makes reversing of embedded systems and industrial control devices partially easier. JTAGulator [2]. A device designed by Joe Grand, aka Kingpin and former DEF CON badge designer, with the sole purpose of identifying JTAG PINs and UART serial lines on printed circuit boards (PCB). There is no need to unomunt or desolder devices. JTAGulator can be configured to run on a range of voltages (1.2-3.3V) and features 24 I/Os that are arbitrarily connected to the board in order to identify the relevant pins. Note, that testing for the valid pinout might cause your little device behave strangely while JTAGulator tries to pull lines up and down. Thus, make sure you stay in safe distance 🙂

Now, you wonder !!!@#$ JTAG!!!…understandably. Joint Test Action Group[3], is the name for a standardized hardware interface (IEEE 1149.1) that allows to test and debug integrated circuits. Most embedded devices (cell phones, wireless routers, …) nowadays implement the interface. Having enough information of the target device, the chip and its peripherals could be initialized and accessed using the JTAG interface. Specifically, the interface could allow access to flash memory contents. Thus, the technology comes in handy to acquire cell phone data on a low level or to extract the firmware of embedded devices.

JTAG interfaces are small boxes that interface between the embedded hardware and a common computer. For example, the Swiss based company Amontec[4] provides a high-speed general purpose interface at low cost (120 Euros). The box and its drivers are compatible with the OpenOCD software[5] an on-chip debugger that allows for programming and debugging of embedded devices using some specific command set and the GNU debugger[6]. The Android community[7] has adopted the approach for debug purposes of the Android kernel [8].

With that, I leave you for the moment and I promise we get back to you soon with more summaries on topics of interest.

[1] Slides and Whitepaper wireless M-Bus Security,
[2] JTAGulater,
[3] JTAG,
[4] Amontec,
[5] OpenOCD,
[6] GNU Debugger,
[7] Android Kernel,
[8] Video Android Kernel Debugging,

Jailbreak detection – curse or blessing?

“Jailbreak Detection” is a set of checks, mostly performed by Mobile Device Management solutions like MobileIron / Good Technologies or other third party Apps to determine if a device is jailbroken or not. It checks if all security controls of Apple’s iOS are still in place and if we can / should / want “trust” this device.

Such a check could for example search for eye-catching files like the Cydia App Store which can only run on jailbroken devices. Other checks may be:

  • Is the root partition mounted read / writable
  • Is it possible to write outside of the App’s Sandbox
  • Is it possible to fork into another process

If we break this down into a sequence diagram it could look like this (for simplicity reasons I divided the app into two components):

To know if a device is jailbroken is very important as it should never be the case that a jailbroken device can access services from the corporate environment like email or document management systems.

Apple itself introduced a jailbreak detection API ready to use for third party developers, but dropped it quietly with iOS 4.2. The reasons remain a mystery. I think Apple was aware of the fact that such an API can never work by design and dumped it for liability reasons: Software is supervising other software, telling it the device is jailbroken … and software can always be manipulated. In this case by disguise the fact that something has been compromised.

The idea is simple: write a malware that will “Hook” the original code and bypass the detection.

The most difficult part of this approach is to find the correct entry point in the code. (Un)fortunately, Objective-C is a huge help and may let us dump all the header files of the implementation. If the developer was nice enough to call its classes “JailbreakDetector” we should be thankful and send him a nice gift:

#import <Foundation/Foundation.h>

@interface JailbreakDetector : NSObject

+ (BOOL)isDeviceJailbroken;


My Hook could look something like this:

+ (BOOL)isDeviceJailbroken{
   return false;

Lucky us, we are not completely at an attacker’s mercy; creative developers exist and have a proper feature set to deal with such attacks. I like the approach that Jonathan Zdziarski published in his book Hacking and Securing iOS Applications. He writes about pushing the attacker into the wrong direction by implementing a decoy class with an obvious naming.While most attackers will first try to manipulate this code, they will by mistake trigger kill switches that for example invoke tamper responses
to erase data and disable remote resources. Other solutions may be to implement the detection as static inline C code, which is much harder to manipulate.

To summarize this post: Jailbreak detection is valuable and it should definitely be a part of your tool-set to secure integration of mobile devices into the company. However, it should not be trusted blindly.


Samba Exploit Development Presentation

As penetration testers, our main goal is to identify as many vulnerabilities as possible. This allows our customers to more objectifly assess their security level and to shut as many doors as possible which an intruder could use to break in. This process needs to be based in respect of cost-benefit, depending on risk probabily and impact. Exploitation is only a secondary objective, mostly used to facility the first one. Also – the fix for most software vulnerabilities is the same: Always update all your software everywhere as soon as possible.

In my spare time, I like to get low-level and study the art of exploitation. From time to time I try to shed some light on the dark art of exploitation, by giving a little presentation to my work colleagues about my findings.

In my presentation I talk about CVE-2012-1182 (“root” credential remote code execution in Samba). First I show a small analysis of the vulnerability itself. After that I outline the inner workings of the Samba heap allocator. Based on this knowledge, I describe how to develop a working exploit which circumvents typical anti-exploitation securiy features like NX, ASLR and PIE.

 I close the presentation with a short analysis of the randomness of libc function addresses of common linux distributions. To summarize, ASLR/PIE implementations in 32 bit Linux distributions do not provide adequate randomness against brute forcing of ret2libc function addresses, as they provide less than 12 bit of entropy. OpenBSD-32bit provides 16 bit, and 64 bit linux distributions more than 20 bit of entropy, which considerably slows brute-force exploiting attempts.

Here are the results of my short evaluation. I generated around 1 million processes, each printing the address of system(), collected them in a file and did some analysis. In the following table, the second row shows the number of unique addresses collected. The third row shows how many times the most common address is being used, in respect to the least common.

It is not really a problem to brute force around <2000 addresses in a suitable timeframe, so the 32 Bit Linux distributions receive a FAIL rating. OpenBSD does a much better job on randomizing LIBC function addresses (as expected). 64 Bit operating systems are the hardest to brute force.

More details in my presentation: sambaexploit_v1.0.pdf

Reversing in God Mode

Fridays, I was approaching a win32 reversing challenge. So I transferred the binary into my Windows XP virtual box and fired-up OllyDbg. The goal was to bypass the username and password prompt that occurred on application startup. Hilariously, I was just providing a dummy name and password to the app…. “asdf” “asdf” as probably most penetration testers have done so, over and over to test logon prompt behavior.

BANG… the app is telling me: “Correct, le clef est Le saucisson vaudois ca rapicole.!”

The force was with me and actually, only Chuck Norris could have topped that :). Was I in god mode? Probably not. Later analysis just revealed that the application required the password to be equal to the username and had some minimal restrictions on the credentials length.

All in all, a 30 seconds exercise.

Lessons learned:
– Implement strong password policies
– Give it a try before you hurry to launch Olly.

Research über die Netkit-Telnetd Schwachstelle

Als ich nach den üblichen Weihnachtsfesten auf Twitter die neusten Sicherheitsmeldungen überflog, bin ich auf einen interessanten Blog Eintrag gestossen:
A Textbook Buffer Overflow: A Look at the FreeBSD telnetd Code.
Der Author beschreibt eine Buffer Overflow Lücke im Netkit Telnet Daemon, der im FreeBSD Betriebssystem verwendet wird. Die Schwachstelle wurde Zwei Tage vorher, am 23.12.2011 veröffentlicht. Details dazu gibt es in CVE-2011-4862. Um die Schwachstelle auszuführen ist kein Benutzeraccount nötig, sie ist einfach auszunützen und ergibt bei einem erfolgreichen Exploit sofort Root Zugang. Zusätzlich verwendet FreeBSD keine der Standard Schutzmechanismen wie ASLR und DEP.

All diese Tatsachen verführten mich dazu, mehr Zeit in dieses Thema zu investieren. Zwei Tage später hatte ich einen funktionsfähigen Exploit für das Metasploit Framework entwickelt. Die Erfahrungen die ich dabei machte habe ich in einer Präsentation zusammengefasst, die ich dann meinen Compass Arbeitskollegen vorgetragen habe. Darin enthalten ist die Analyse des Fehlerhaften Codes, worauf eine kurze Abhandlung des Telnet Protokolls folgt. Mit diesem Vorwissen bewaffnet werden die einzelnen Stufen des Exploits detailliert erklärt, mit Veranschaulichung durch Aufnahmen des Netzwerkverkehrs, grafische Darstellung von Datenstrukturen im Telnet Deamon und Details aus dem Metasploit Modul. Abschliessend sind noch typische Anti-Exploiting Mechanismen vorgestellt, und wie es möglich ist diese zu umgehen.

Die Präsentation kann unter diesem Link heruntergeladen werden: