Iodine DNS Tunneling

I first wrote about DNS Tunnelling back in 2010. Even back then, commodity tools to facilitate it were at least five years old. I covered OzymanDNS, DNS2TCP,Heyoka, and DNSCAT in 2010.

A few years ago, I was introduced to Iodine, and it's been my go-to tool for DNS tunnelling ever since, frequently with great success. Iodine has several different modes, and will try various query types, packet sizes and timing parameters, usually making the connection as reliable as it can be. Without any adjustments, it doesn't try to be stealthy, but if you dig into the manual client options and you know what your adversary is looking for (e.g. Snort/Suricata rules, Bro, FQDN length, volume of queries, etc.) you might be able to get Iodine to fly below the radar.

Just like the very first articles I wrote, the technique requires you to set up a sub-domain with a name server. Here, I set up a subdomain for *.t.h-i-r.net, and I've assigned it a name server of tn.h-i-r.net. I had to specify an A record for it: the IP address of a VPS I'm leasing (which also hosts much of HiR's presence aside from this blog). You could easily point it to your home IP address -- so long as you can NAT port 53 UDP to it.

I'm using Google Domains for this, but almost any DNS control panel should let you define NS records for subdomains and A records for hosts similar to how it shows up above. Previously, I'd demonstrated using GoDaddy and ZoneEdit DNS control panels.

Once you have established these DNS configuration entries, and made sure that UDP traffic can get to port 53 on the tunnel server, you should be ready to get Iodine installed. Most GNU/Linux and BSD flavors I've used lately have Iodine in the package repository. That includes OpenBSD, Arch Linux, Kali, and Ubuntu. If you're using Mac OS X, there's a Homebrew recipe that seemed to work last time I tried.  The Iodine page has Windows and Android binaries available for download. I have not yet tried them.

You probably want to leave the iodine server (iodined) running on your tunnel server at all times, so that it's ready when you need to use it. Since iodine uses a privileged port and creates TUN/TAP interfaces, you need to run it as root. At a minimum, to start the Iodine server, you need to specify a password, a network (in CIDR notation) to allocate for the tunnel, and the subdomain you configured above. I'm using a pretty small network mask (/29) which allocates only five client IP addresses. As I'm the only one using this tunnel server, this is fine. It might even be overkill.

# iodined -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Setting IP of tun0 to
Adding route to
add net gateway
Setting MTU of tun0 to 1130
Opened IPv4 UDP socket
Limiting to 5 simultaneous users because of netmask /29
Listening to dns for domain t.h-i-r.net
Detaching from terminal...

On the client machine, it's assumed that you can connect to a network, but unrestricted Internet access isn't working. In my example, I'm on a somewhat restricted hospital Wi-Fi network that isn't allowing SSH, and has restrictions on what one can browse on the web. Most of my favorites are being blocked because they're "hacking" related.

Ideally, a recursing DNS server is available. As long as you can see the NS record you set up, there's a pretty good chance Iodine will work. The client also needs to run as root (or via sudo) and the bare minimum configuration requires a password and the subdomain.

$ host -t ns t.h-i-r.net
t.h-i-r.net name server ns.t.h-i-r.net.

$ sudo iodine -P r3d4c73d t.h-i-r.net
Opened /dev/tun0
Opened IPv4 UDP socket
Sending DNS queries for t.h-i-r.net to
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Setting IP of tun0 to
Adding route to
add net gateway
Setting MTU of tun0 to 1130
Server tunnel IP is
Testing raw UDP data to the server (skip with -r)
Server is at, trying raw login: OK
Sending raw traffic directly to
Connection setup complete, transmitting data.
Detaching from terminal...

Once you have the connection established, the remote end should be reachable via the "Server tunnel IP" shown in the output. In this case, that's Typically, this is where I set up a Dynamic proxy with ssh.

$ ssh -D 1080
Last login: Thu Oct 20 17:44:19 2016 from
OpenBSD 6.0 (GENERIC.MP) #0: Fri Sep  2 16:10:46 CEST 2016


Back in the real world, I set Firefox proxy settings up to use localhost at port 1080, and enabled remote DNS. Configuring the proxy in other browsers may vary. You may even have a system-wide SOCKS proxy setting.

Firefox now can browse through this SSH session, which is tunnelling over DNS.

Back on the tunnelled SSH session, I used the ~# SSH escape command to list open tunnel connections. This will verify that you are browsing through the tunnel.

The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
  #3 direct-tcpip: listening port 1080 for www.h-i-r.net port 80, connect from port 16128 to port 1080 (t4 r1 i0/0 o0/0 fd 9/9 cc -1)
  #4 direct-tcpip: listening port 1080 for www.blogger.com port 443, connect from port 25392 to port 1080 (t4 r2 i0/0 o0/0 fd 10/10 cc -1)
  #5 direct-tcpip: listening port 1080 for apis.google.com port 443, connect from port 46746 to port 1080 (t4 r3 i0/0 o0/0 fd 11/11 cc -1)

It's hard to see here, but I grabbed a Wireshark screen shot of Iodine in action a few weeks ago. The heartbeat packets are all pretty short. They can get quite large when the time comes to send a lot of data. Here, Iodine has chosen to use NULL records.


Laptop CPU upgrade -OR- The quest for OpenBSD vmm(4)

I have been itching to play with vmm. I tried to get it working on an old Acer laptop and an IBM System X server, without any luck. I asked what was up, and heard from jbg@ that vmm requires a CPU with Nehalem microarchitecture or newer, and that the Intel P6200 in this machine lacks some of the instructions needed for vmm. Well, that would have been nice to put in the documentation. Perhaps I'll submit a diff.

I decided it'd be fun to try to upgrade the CPU in the Acer so I can finally play around with vmm in -CURRENT. Believe it or not, I've never attempted a laptop CPU upgrade. I've only replaced CPUs with the same spec before, replaced thermal interface compound, and upgraded RAM and hard drives. I went on the hunt for  PGA988 (Socket G1) Arrandale-based processors with 35w TDP (so the existing heat sink and fan, designed with the P6200 in mind, can keep up).  Sure enough, some of the first-generation i5 and i7 mobile processors fit the bill nicely.

On a really tight budget, I scored an i5 540M for $12 shipped. At the high-end, I could have splurged on an i7 640M to really wring everything out of it -- as far as I can tell. The only difference between the CPU I bought and the best i7 I could shoehorn into this laptop are an additional 1MB of SmartCache and 250MHz. Since my goal was simply to get vmm working, $12 was a bargain.

Many laptops make it a breeze to change hard drives. Some even have easy access to swap RAM, WiFi adapters, and optical drives. This Acer is easily serviceable for these parts. The CPU is a bit more difficult to get to. It's on the bottom of the motherboard, and it requires one to remove the keyboard, the top of the base, remove a handful of ribbon cables and connectors, and completely remove the motherboard, heat sink and cooling fan as a single assembly. Once the board is exposed, it's pretty simple to remove the heat sink, open the socket and swap processors.

P6200 (left) and i5 540m (right) immediately after swapping processors
The most crucial part of upgrading the CPU is making sure you have a good thermal interface between the processor dies (shiny metallic parts) and the body of the heat sink. I used a thermal paste that I've had good luck with in the past. For a 35w CPU, you don't need to splurge, but you should follow the instructions closely if you are unfamiliar with the process.

I slapped most of the parts back together without re-assembling the entire laptop case to see if it would even boot. Remember, this was uncharted territory for me. Looks like success!

Core i5!
Of course, there's still a matter of whether the BIOS will pass the virtualization options to OpenBSD. This is basically the worst BIOS setup I've ever seen, and it doesn't give me any options for virtualization.

I had already compiled a fresh OpenBSD kernel with vmm(4) enabled, so I went ahead and put the laptop back together, and booted the vmm capable kernel,started vmd and fired up the virtual machine.  No errors! I attached to the virtual serial console, and a few seconds later, saw the kernel booting.

Sweet success!

This coming weekend, I'll probably try to figure out how to get networking configured. This definitely isn't Parallels Desktop, but it's not any more daunting to set up than QEMU was.


Pretty WordPress permalinks under OpenBSD's httpd(8)

I run a bunch of websites on OpenBSD. One of them is running WordPress for a local group. When I upgraded the server from OpenBSD 5.7 to 5.8 last year, I finally switched from the version of Apache 1.3 that used to come in the base install, to the new relayd-based httpd that had been in the works. Without mod_rewrite, I disabled the so-called "pretty" permalinks with useful titles, going back to the old numbered-posts setup.

This had been bothering me last weekend, and earlier this week, I saw someone else with the same problem. I had written a totally custom CMS for one of my other websites, and it also uses an awkward set of front-controllers written in PHP in order to make friendly-looking URLs. I decided to explore my method of setting that site up, applied to WordPress.

You have the option of using so-called "PATHINFO" Permalink URLs in WordPress. Those might look like:

That's getting there. I opted to make my site more like:

I started by creating a symbolic link called "posts" pointed to index.php.

ln -s index.php posts

Since I'm using PHP-FPM, I had to also make sure that FPM would acknowledge this new file since it lacks the .php extension.  Beware the rule of unintended consequences here. You'll want an airtight httpd.conf when it comes to what things it decided to toss over to the PHP-FPM socket. Blank out the security.limit_extensions variable in /etc/php-fpm.conf

security.limit_extensions =

Next, adjust your httpd.conf to send stuff destined to the /posts URI (note the * at the end, it's important!) to PHP-FPM. All of my sites are under /var/www/sites/ (including the one I'm setting up WordPress on). My httpd.conf clause for this site looks kind of like this:

server "blog.foo.com" {
    listen on $ext_if port 80
    alias "fooblog.com"

    log access fooblog-access.log
    log error fooblog-error.log
    directory {index "index.php" }
    location "/*.php*" {
        root { "/sites/fooblog" }
        fastcgi socket "/run/php-fpm.sock"
    location "/posts*" {
        root { "/sites/fooblog" }
        fastcgi socket "/run/php-fpm.sock"
    location "/*" {
        root { "/sites/fooblog" }

You'll need to restart php_fpm and httpd for this to take effect.

doas rcctl restart httpd
doas rcctl restart php_fpm

After that, log in to your site's admin panel and change the permalink structure to include "/posts/" at the beginning. You should be all set.


NetBSD 7.0 working on the Raspberry Pi Zero

The NetBSD Wiki has a nice page about Raspberry Pi support, including instructions for finding a nightly snapshot image for Raspberry Pi SBCs.

Trying to boot the latest snapshot (201512311300Z) on my Pi Zero resulted in 8 flashes of the OK/ACT LED (bootcode.bin and/or start.elf problems, according to the documentation). This image boots fine on my Pi B+ and Pi 2.

I over-wrote bootcode.bin, start.elf and start_cd.elf on the freshly imaged NetBSD SD card from the version on my Pi Zero Lapdock (installed from a recent Arch Linux image. NetBSD 7 now boots on the Raspberry Pi Zero. I don't know if these are exactly the correct files, but I suspect they likely require updating in the NetBSD base image.

I've included MD5 sums of the files for your convenience: From the NetBSD Image: 
MD5 (bootcode.bin) = 9a4ad6a12ad7dc1aae279888c25d2252 
MD5 (start.elf) = a2c4b9ea3ae986f88ea01e05bef46904 
MD5 (start_cd.elf) = 85924312c9b51d1ef5b7ca301bb18d54

Files I copied over from Arch Linux that make it bootable: 
MD5 (bootcode.bin) = 6cc6560c0178c10928d14b8768969dab 
MD5 (start.elf) = f5b2a422d863efe5d47b1ac291ccaa3a 
MD5 (start_cd.elf) = f0dfc1462c5d9b003b64428fd52406ed

(I posted a variant of this as a comment on the NetBSD wiki. It hasn't shown up yet. It likely requires approval)


No more "Hacky GNU Year"

I usually kick off every year with the aforementioned greeting, but 2015 will stand as the year I really got sick of what the GNU/Linux ecosystem has become... in pretty much the same way I have been sick of what the Windows ecosystem has become. The mainstream Linux distributions have all become painful to me in ways that I couldn't have imagined just a few years ago. It's been a long, arduous slog. You can ask any of my nerd friends. I've gotten pretty salty over the state of Linux in the past year. And don't get me started on the nightmares of El Capitan and Windows 10, also making 2015 especially brutal.

This evening, though, Linux is weighing especially heavy on my mind.  I'm sure the recent passing of Ian Murdock has something to do with it as well. We really did lose one of the heroes this week.

I will still use Linux and Windows for the tasks that they excel in. I will continue to experiment with and master their secrets in order to figure out how they work -- just as I do with other operating systems.

My new year's resolution is to get more and more of my personal stuff migrated to some kind of BSD.

Best wishes to all of you in 2016 from Ax0n.


Raspberry Pi Zero inside a Lapdock 100

A lot of folks have used the Motorola Lapdock as a portable complement to the Raspberry Pi. It usually ends up as a big mess of cables. My Lapdock was actually used a lot with my last phone, as it was intended to. Occasionally, people would ask me if I was using it for a Pi. My response was "If I can figure out how to fit it inside, I'll try." I always figured it would involve de-soldering all the GPIO headers, network and USB jacks to make it thin enough to fit, then a bunch of soldering to hard-wire everything together.

With the announcement of the Raspberry Pi Zero, I knew it was finally time.

I did a little bit of recon inside the Lapdock case. Plenty of room for a Raspberry Pi Zero and some cables.

Opening up the LapDock isn't too hard. Start by prying the keyboard loose from the top, with a small flat-blade screwdriver or a spudger. Underneath, you will find a single ribbon cable for the keyboard, and a number of screws. Remove the keyboard and all visible screws. The only thing left holding the case together after that are the four screws on the bottom case, one at each corner.

Once I saw the layout inside, my plan was to place some pigtail connectors inside the chamber that the dock connector rests in when not in use. The speaker on the left bottom corner is kind of in the way.

I ordered two cables from Amazon:
Micro HDMI Female to Mini-HDMI Male
USB On-The-Go Extension

I tested everything outside the lapdock first.

Miraculously, both cables worked great. I'd read many horror stories of HDMI cables and adapters that didn't work well with the Raspberry Pi. Not bad for 12 bucks.

Inside, I got to work. First things first, remove the speaker, held in by two screws. Remove the battery, too. It sits loose in the case and is easily unplugged.

At this point, it was obvious to me that I couldn't put the pigtails inside the case where I had planned. There's just not enough room under the speaker. I took the top case apart a little further by removing the screws marked below.

I cut away a little piece of plastic under the speaker to open up some space near where the dock cable rests.
Then, I pried apart the upper part of the dock on one side, giving me enough room to make a cross-shaped hole in the rubber dock membrane by making two slices with a knife.

I'll have to run the pigtails through this corner of the phone dock. I routed the cables through the maze of plastic and shoved them through this hole.

I had to make sure the plugs were oriented properly for a good fit with the dock connector.

To make room for the Pi, I took a knife blade to some of the plastic structures inside the case. A tab (not shown) on the lower case lid also needed to be trimmed.

The final part before reassembly was trying to find a good way to route the cables so that the Lapdock could be reassembled nicely. I held the Raspberry Pi Zero down with some double-sided foam mounting tape once I had everything in position. This tape also insulates Pi from the metallic coating on the inside of the Lapdock's case, so don't skimp on it.

Once everything was buttoned back up, I plugged the dock connector into the pigtails again and powered the dock up.

The end result is a nice, self-contained computer powered by the Raspberry Pi Zero, but the dock is still usable for other devices.

Update: 2015-01-24

Frequently, you have to use the reset button on the bottom of the lapdock to get it to boot proplerly, and I wanted to be able to reset the dock with my pinkie finger. Also, I wanted a way to easily swap out MicroSD cards. To fix these two issues, I used a stepped drill bit to enlarge the reset pinhole and to give me access to the Pi Zero's card slot.


PiTether: Mobile phone to ethernet bridge


If you saw me at DefCon this year, you probably saw me using my HP Jornada. There was also a pretty good chance that you saw me getting it online in strange ways...
HACK THE PLANET! (Or just dial up a BBS...)
Since there aren't payphones everywhere, though, I built something interesting back in May, preparing for DefCon. It's a very simple Raspberry Pi ethernet bridge. I did this mostly to avoid using the open WiFi at DefCon, understanding that 3G/4G shenanigans are happening, but with a higher barrier to entry than the 802.11a/b/g/n/ac mess.

Yes, that's a Raspberry Pi Model B inside a case made of LEGO bricks.

Setting up Arch Linux

Being no stranger to building embedded systems, I decided to go with a bare-bones Arch Linux ARM install on a 2GB SD card. You could likely run with an even smaller card if you wanted to. The installation instructions are pretty straight-forward if you're familiar with the command line.

Once you have Arch Linux up and running on the Pi, I recommend changing the default passwords (alarm/alarm, root/root) and then doing a system update to get the latest packages from base. Simply connect the Pi to the Internet through its ethernet port, then run "pacman -Syyu" as root.

Configuring the network

The 3 interfaces we worry about are eth0, usb0 and br0. The first two basically work right out of the box:

/etc/systemd/network/eth0.network exists from the default installation, so the ethernet port is already set up for us.

When you activate USB Tethering from Android while plugged in to most modern Linux distros, it shows up as a network device (in this case, usb0) without any extra configuration.

br0 (the bridge interface) needs to be configured. First, we establish a netctl profile for it. Put the following text into a file called /etc/netctl/br0

Description="PiTether USB/Ethernet connection"
BindsToInterfaces=(eth0 usb0)

Next, create a service file for systemd that calls netctl for the br0 interface. Put these contents in /etc/systemd/system/netctl@br0.service
.include /usr/lib/systemd/system/netctl@.service

Description=PiTether USB/Ethernet connection
Run the following command as root to enable the interface during start-up:

netctl enable br0

Reboot the Pi to make sure everything works as planned. To test:

  1. Plug in your phone and activate USB Tethering.
  2. Plug a device into the ethernet port of the Raspberry Pi
  3. Request a DHCP Lease (happens automatically on most devices)
  4. Try to browse the web or connect to something over the Internet (ping, ssh, etc)
As a finishing touch, I decided to make the entire filesystem read-only. This makes it so that the device can be safely powered off by simply unplugging it without any risk of corrupting the filesystem. I did this so that I never needed to SSH to it or hook up a console to safely shut it down. Since this is really a single-use project, this works pretty well. For more elaborate embedded-system work, I usually opt for a RAM disk configuration, but that's not needed here.

You can probably do this by sliding the write-protect tab on the SD card (for Pi A and B only) however, I opted to mark both filesystems "ro" in /etc/fstab. Apparently, root (/) is optional in fstab, but I added it by copying the /boot line and slightly altering the device and mountpoint fields. My /etc/fstab looks like this:
# /etc/fstab: static file system information
# file system   dir     type    options         dump    pass
/dev/mmcblk0p0  /       ext4    defaults,ro     0       0
/dev/mmcblk0p1  /boot   vfat    defaults,ro     0       0
You can give it one more reboot and test after that if you want. If you ever want to change anything in the filesystem, you can temporarily remount it read-write again by using the command "mount -o remount,rw /" while logged in as root. You can use that to remove ",ro" from the fstab options or to occasionally update packages.