Software-Defined Radio

I had been toying with the idea to get a Software-Defined Radio (SDR) stick for a long time now; even though they’re fairly inexpensive, I’m not one for making impulsive purchases. I mean, what am I going to do… Listen to the radio using my laptop? Seems a bit overkill.

When one of my colleagues mentioned he was starting a project and had ordered an SDR-stick and another coming forth as a licensed ham operator, it pushed me over the line and I ordered one as well. Some basic Googling showed that SDR is possible using DVB-T receiver USB-sticks. Some clever people figured out that the fairly inexpensive sticks can be used to receive a wide range of the radio spectrum, partly due to the lack of a frequency filter and because the sticks pass through the raw data over the USB connection.

Honestly, I am not very well-versed in electronics or radio, but I find it very interesting. The folks over at seem to know what they are talking about and have good documentation, so this seemed like the stick to go for. In addition, the connector used by this SDR stick is an SMA connector, which is frequently used for things like satellite antennae. By ordering this one, I would be quite sure that it would not be too hard to find new and better antennae if I would stay interested. Unfortunately, the official retailer for the stick specified in their agreement they would send the device within 48 hours, they happily took my money and went silent for three days.

As I was still very excited to play about with SDR, I ordered a cheaper USB DVB-T stick based on the RTL820T2 chip off It was due to arrive the next day. Fortunately, both arrived on Saturday, and Monday was the second day of Pentecost and I would have three days to play around with them.

The licensed ham operator advised me about setting up the dipole: make each leg a quarter wavelength and make sure both legs are in-line with eachother for the best reception. Wikipedia, YouTube and (again) the RTL-SDR site helped me with the rest. While antennas can seem very daunting, the basic principle is incredibly simple.

Radio transmissions are polarized and if you try to receive a vertically polarized signal with a horizontally oriented antenna, you’re going to have a bad time. RTL-SDR page mentions that most terrestrial (Earth) signals are vertically polarized, so a vertical setup would yield the best reception.

This also explains why car antennae are usually oriented with a slight slant to the back. The almost-vertical orientation picks up the best signal, while the slant is both aerodynamic and allows horizontally polarized radio waves to also be picked up, albeit with significant losses. FM radio is generally an incredibly strong signal.

FM-broadcasts around 96.8 MHz. The signal is so strong that the automatic gain control completely blocked out the other signals.

With this knowledge, I set up the antenna inside, using gqrx as a spectrum viewer and audio decoder. This worked extremely well for FM, but not so much for any other radio frequencies I was trying to listen to. For example, the Schiphol airport approach (west) frequency was almost inaudible. The next day had a lot better weather and I mounted the antenna outside using the supplied suction cup mount, positioning the antenna vertically and using the extension cable so I was able to sit comfortably inside.

Schiphol approach on 121.2 MHz, also marked in the screenshot. The signal is incredibly faint with an antenna placed inside.

The difference in signal reception was staggering, not only could I hear approaching planes for more than 50 kilometers away, the almost clear line-of-sight between me and Schiphol allowed me to listen to the air traffic controller as well.

Schiphol Approach West frequency (120.200 MHz). Communication between Tower and different aircraft.

SPF mapping tool

Since the last time I wrote something about e-mail (March), I mentioned Sender Policy Framework (SPF). This standard allows anyone to publish information about which IP addresses are allowed to send mail on that domains’ behalf.
As SPF is quite complicated in some ways, I could not find a tool that would nicely list all IP-addresses which are allowed, so I made one myself! It clearly shows all directives and what it results in. All nodes are IP-addresses and all edges are directional arrows, showing which node led to each IP-address.
Tool is available on
The colour of each node represents the result it signifies; green is pass, bright yellow is neutral, grimey yellow is softfail and red is a hard fail.'s SPF record’s SPF record

Apart from being useful to check your SPF records, because I used the open-source library visjs, it’s also incredibly fun to play with. Each node has gravity and all edges are springy. Apart from the physics, it’s also fun to map out some domains and see all the different IP-addresses that are included in their SPF record.
Food for thought here: By allowing so many different providers (IP-addresses) in your SPF record, an attacker only has to compromise a single server in all that address space in order to succesfully allow a mailserver to accept his email as being from you.

Stop leaking information

In the past I used to write my own simple CMS (Content Management System) for my own website and for friends. This ensured every website did exactly what everyone needed, but had to be maintained by me. WordPress takes all that hassle away and has an incredulous amount of themes and plugins available right out of the box. It also allows for an enormous level of tweaking. Each and every call is pretty much “hookable”, allowing anyone to write a plugin to do anything they wish when a function is called. This all allows for great flexibility, but for me – trying to host WordPress from my seven year old NAS – pages can take a long time to load. Up to ten second per page. Adding plugins from the store that promise caching, were only speeding up the site by a second or so as most of the PHP-code in most of the files was still being executed.
On the other hand, setup for a WordPress-site is so easy;
With the enormous user-base that WordPress has, as new exploits are found and released into the wild, hackers roam free and kidnap WordPress websites by the thousands. These websites are frequently used for phishing scams and hosting malware. In one event, a hacker group who infiltrated high ranking government officials for a country I can’t remember, used a couple compromised WordPress site as their C2 (Command and Control) servers.
With the (currently) most recent patch 4.7.2, a vulnerability was discovered in the REST-API, allowing anyone to post any message to any WordPress-website. Even though most actual WordPress users have no idea what a REST API is and why they are running it on their site, apparently it has been enabled by default starting in WordPress 4.7. A quick look in the admin panel showed no way of disabling this API either.

So… many… features…

There’s a tool available online called WPScan, which does exactly what it says. It lets anyone scan any WordPress installation and it will tell you so many things about the website. Apparently WordPress inserts version numbers everywhere, has dozens of features that are “always-on”, but (for me) lead to no extra functionality.
Extra features are not always a good thing. I mean, sure, for the administrator and the user, they probably are. But as in most cases, more features mean more code to maintain. As the codebase grows, you would expect the same for any bugs which can be exploited.
Googling for how to disable most of the WordPress-features, leads  to writing PHP-code into your /wp-content/functions.php  directly. This most likely works fine, but any WordPress update will update the file, deleting your lines in the process.
As such, I have taken matters into my own hands. Looking through the available plugins did not leave me with a very good feeling. Most plugins promising security either require payment or consist of dozens of files, leaving me no quick way to audit the code. By writing a “plugin” PHP-script, which needs to be enabled in the WordPress admin area, the script does not touch any core WordPress files and should never be manipulated by any update.
Instead of providing the entire file, with no context, I will do a quick rundown of most features I have disabled and why I have done this.

Firstly, complying with WordPress plugin dynamics

So, before we put any code down, WordPress expects to extract some basic information from the file, it looks a little like this:

There’s some information in there, which WordPress expects: an  author, a name and and description it can display for the plugin etc.
In  addition, there’s a quick check for the constant ABSPATH  as this is a constant set by WordPress and if it’s not there, the plugin is not requested  by WordPress and we better not call any functions.

WordPress “features”

There are a number of “features” in WordPress that I do not think of as features, such as:

  1. Generator tags on every page, specifying that WordPress was used to generate this page.
  2. An RSS-feed, which leaks data such as a version number.
  3. A REST-API for which I have no use and do not want anyone else to use.
  4. XMLRPC, which allows for “pingbacks” (saying: I linked to your page from my page!), but in the past have been used for DDoS attacks. Personally,  I have no interest in who would link to me.
  5. Adding query parameters to stylesheets, specifying which WordPress version I’m using.
  6. Providing a nice readme.html file which sits in almost anyones WordPress installation, telling anyone who’s interested what version I am running.

For most of these, they “leak” information that I do not want everyone to know. This includes, for example, my WordPress-version. Even though I update my WordPress whenever I can, this does not mean I am not a human and cannot forget.
For most of the above, I am simply checking the URL and killing the script when it detects a URL being requested that I do not want available. For others, I have simply reduced the file permissions to  “000”  (no read access, no write access, no execute access), meaning my webserver is not able to read the file and thus shows a “Forbidden” screen. This also means WordPress will not be able to update the file or change any permissions on it. Effectively taking it out.

Disabling WordPress “features”

For the readme.html, all I did was reduce the file permissions to 000, allowing nobody to  access to the file.

Hooking into function calls

Most google results for “disabling xxx wordpress” will lead to adding code to pages which consist of add_filter('filter_name', '__return_false');  meaning they will no longer function.
I have combined a few of those here, mostly found through Google:

In addition, as the plugins PHP-code is called on each and every page, before outputting any data to the web browser, I have resorted to simply killing the script on specific requests:

If the URL requested contains /feed , xmlrpc.php  or /wp-json , it simply exits the script and shows no output to the user. This is the most effective way I have found of disabling these “features”.