Breach response planning, set to music!

Posted in General Security, Silly on 29 October, 2015 by Alec Waters

It’s the graveyard shift at the SOC. Ana and Elsa are on duty, when suddenly it becomes clear that Bad Things are afoot. The nightmare scenario has come about – the Evil Hackers have come for them, and now the company has got to deal with it. To keep their spirits up, they sing along to the Incident Response plan – now you can sing along too!

The lights glow red on the console tonight
Not a green tick to be seen
A network of desolation,
And our Brand has lost its sheen.

Twitter is howling like this swirling storm inside
Couldn’t keep it in, heaven knows I tried!

Don’t let them in, don’t let them see
The pastebin boasting of the hacking spree
Conceal, don’t feel, don’t let them know
Well, now they know!

We got owned, we got owned
Can’t hold it back anymore
We got owned, we got owned
Journalists are at the door!

I don’t know
What they’re going to say
Can I fob them off..?
The press never bothered me anyway!

We had a load of warnings
Of our impending fall
And the hacks that once seemed far-fetched
Have left us feeling mauled

The hackers showed what they could do
To test the limits and break through
No right, no wrong, no rules for them
They’re free!

We got owned, we got owned
I am suddenly feeling shy
We got owned, we got owned
Today you’ll see me cry!

Here I stand
But not for long
Time for me to hide…

The share price flurries through the air into the ground
It’s time to fire someone and change the branding all around
Re-skin the website, change our name and do it fast
The share price rises back,
The past is in the past!

We got owned, we got owned
You’ll forget by the break of dawn
Who got owned, who got owned?
That memory is gone!

Here I stand
In the light of day
Business carries on,

HackFu 2015 – The Badgening

Posted in General Security, Hardware, Packet Challenge on 16 June, 2015 by Alec Waters

Flashback to August 2014. Planning for HackFu 2015 is well underway:

Alec: Hmm, maybe HackFu could use a bit of DefCon-style badge hacking..?
Martyn (MWR): Can we do something cool for £10-£20 per badge? Max 100.
Alec: No problem.

Fast-forward to June 2015, skipping out many months of design, construction, frustration, late nights and burned fingers:



What you see here is a box containing 102 of these:



Note the important instruction written at the top of the board

More pics from the event can be found on MWR’s Facebook page, and there’s a video report from the event courtesy of SC Magazine.

Here’s the spec of the badge:

  • Ciseco/WirelessThings RFu-328 Arduino-compatible radio transceiver
  • 3.3v TC1015 PowerPOD power regulator
  • 1.8 inch colour TFT display, 128×160 resolution
  • SD card slot
  • 5-way joystick
  • Serial port
  • 3xAA battery box
  • I2C edge connector. More on that later on.
  • Hackable gameplay! More on that later on, too.

It’s a long way from the prototype:


This is based on an RFu development board and a Nokia 5110 mono LCD (48×84 resolution).

The venue for HackFu 2015 was ex-HM Prison Ashwell, closed in 2011 and now run by The Gaol Events as an urban airsoft site. The venue was chosen to match HackFu’s theme – the premise was that all of MWR (and guests!) were incarcerated, as some of them were suspected of being involved in plotting acts of cyber-nastiness. The name of the game was to identify the guilty and exonerate the innocent, although I’m not sure how many of these people look innocent:


So how did the badges fit into the gameplay? They had two primary functions:

  1. They contained each prisoner’s characteristics – their convictions, addictions, skills, and tattoos. You can see this on the menu screen on the picture above.
  2. They allowed the prison to track the inmates around the venue by means of their on-board SRF radio modules. There were three base stations around the prison which would “ping” each badge in turn. A reply from a badge equated to “loyalty” (because you’ve not absconded) and increased a global loyalty score for all the teams combined. At different point levels, new areas of the venue became accessible and rewards were given (“party” and “free booze” being two of them!)

The base stations looked like this, and comprised a WirelessThings Xino-RF, an Arduino ethernet shield, a clear acrylic enclosure, and some elastic bands:





It’s “upside down” in the enclosure so that I could have a wire whip antenna poking out. The ethernet shield is so that the base station can call web services on the game network to register the presence of the badges.

There were dozens of challenges for the inmates to attempt – the reward for successful completion of each wasn’t points (as usual), it was a clue to the identity of one of the guilty parties. Clues were of the form “the mole does not have a conviction for Racketeering”, or “the mole does not have a tattoo of tempura battered prawn” – this meant knowing all of the prisoner characteristics for all of the badges (even those of people on other teams) was critical to success. Now, you could just go around and ask everyone what’s on their badges, or perhaps you could find another way to get the information that doesn’t involve bartering with other teams…

The final menu item on the badge is “Maintenance Mode”. Selecting it shows you some stats and config about the radio module; it also warns you that the radio is inactive – this means it’s no longer responding to polls and is no longer contributing to the overall loyalty score (this is Bad! Remember there’s a party and booze at stake!)

Why is the radio inactive? The SRF module on the RFu board is attached to the “Arduino’s” serial port – if you want to talk to the Arduino, you have to turn off the radio – you can’t do both at the same time. If the inmates connected to the serial port whilst in Maintenance Mode they were presented with a request to enter a PIN – the challenge here is to write a simple brute-forcer that would operate over the serial port.

The reward for getting the PIN is a download of a “badge toolkit”. This consisted of a Python script and a dissector for Wireshark written in Lua. The purpose of the script was to allow the teams to use their issued SRF-Stick USB radios to sniff the radio network and have Wireshark parse the packets. I was using the RadioHead Packet Radio library – the badges would listen for RHReliableDatagrams (sent via the RH_Serial class), send an ack back to the sender, and act on the contents.

The problem here was that the stick could only see traffic to team’s own badges – the SRF supports the concept of logical separation of traffic via a PANID, and each team had their own (think of PANIDs like VLANs on an ethernet switch). If the teams looked at the contents of the Python script they’d find a simple tweak they could make. The script put the SRF into ATZD1 mode, allowing it to hexdump all traffic on its configured PANID. Commented out was a line which put it into ATZD2 mode instead – this hexdumps traffic on all PANIDs.

So now the teams can see all the traffic; if they look into the Lua dissector, they’ll see all of the message types the badge supports:

  • ping – this is the standard “are you there” message sent by the prison
  • IDNUM – causes the badge to output the prisoner ID number over the radio net
  • SKILLx – causes the badge to output skill number X over the radio net
  • CONVIx – same for conviction X
  • TATTOx – same for tattoo X
  • ADDICx – same for addiction X
  • CHPIDx – causes the badge to swap PANIDs (i.e., cause a badge to “change teams”)

So, how does one send one of these messages? Inside the badge toolkit zipfile was a file called .gitignore. Which most people ignored. Because it’s .gitignore. Except it wasn’t – it was another Python script that allowed the user to send a ping to a badge and included all the necessary code to calculate the packet’s CRC. This could then be modified to send any of the other messages, with the results captured in Wireshark. Now the teams can start harvesting prisoner characteristics from all badges, and the answers to the other challenges will make sense.

So what’s the CHPID message for? Why cause a badge to change PANID? Changing PANID will also cause the badge to change the primary colour of the display – each team has their own colour and PANID, and if you change PANID the badge will change colour to match.

It turns out there’s a side benefit to accruing loyalty points, namely cold, hard cash. At the end of every sweep, the prison would work out how many badges were present and which PANIDs they were on. Money was then distributed to each team captain based on the number of badges seen on their team’s PANID. If you can command a badge to change its PANID to yours, that gets more money for your team. Cue “Badge Wars”, where people’s badges were rapidly changing colour as teams vied for control!

So what about the “Loyalty Enhance” menu option? Selecting it merely says “Enhancer not found”, with no other clue as to its purpose. However, one of the items on sale at the HackFu shop was a “nunchuk” (note singular, not plural). Purchasing one of these gave you a Wii Nunchuk, and connecting this to the edge connector made Loyalty Enhance do this:

Tetris, baby!

Tetris, seen here on an earlier version of the board

By levelling-up in Tetris your badge’s response to a prison poll counted for more (a “loyalty multiplier” if you like) – up to sixteen times more if you played it for long enough, potentially allowing a team to reap huge rewards. But there weren’t many Nunchuks to go around, and it takes ages to get to that kind of level in the game. Surely there’s an easier way?

“Easier” probably isn’t the right word, but the Yellow Team (the “Framed Packets”) figured it out. At the peak of their activities, they were netting over £30,000 of in-game currency per hour – you can read about how they did it here. Extra credit also goes to the Green Team (the “Barred Coders”) for downloading the firmware from the badge, removing all the troublesome CHPID and SKILL/etc commands, and reflashing their patched code. Credit goes to all of the teams for their efforts – they all dug deep.

Lessons learned

This was the first time I’d designed a board and made something “proper”. There were a few things I picked up along the way:

  • Make sure you get the Eagle files right before sending them off to the board house! My first run of boards had the four pins at the top of the display 180 degrees out, preventing the use of the SD card slot.
  • Test the boards when you get them back, and before you solder any components on. Some of my boards had dodgy soldermask, much as you see here. It’s quite frustrating to discover this later rather than sooner, but that’s what sometimes happens when you use a cheap Chinese board house (although apart from a few dodgy ones, the boards and the service from DirtyPCBs represented excellent value for money!)
  • Get a Panavise Jr! Assembling over 100 boards without one would have been more torture than it actually was.
  • Don’t do something so monumentally daft as committing yourself to a project that involves making over 7,000 hand-soldered joints (each badge has 70 joints) :)

At the end of this year’s event, I was issued an instruction for HackFu 2016 – “come up with something awesome”. Hmmm, let’s think…

Who are you?

Posted in General Security, NSM on 19 September, 2014 by Alec Waters

Unwanted email is as near a certainty in life as death and taxes. “Selling” spam is a nuisance; phishing emails or messages bearing hostile attachments have the potential to really ruin your day. A lot of the time there are dead giveaways that the message isn’t what it appears to be – the grammar is usually poor, or perhaps the message is claiming to be from a company based in a foreign country that you’re unlikely to be doing business with.

We’ve all chuckled at poorly written messages, but what if the message looks like this?

cdsOr this?

furnituremarketThese are a little more convincing, because they’re copies of actual emails from these two companies – the companies, people and phone numbers all exist and are genuine. The messages are also targeted a little better – they claim to be from a UK company, and are sent to a recipient in the UK, meaning they’re more likely to be read and perhaps acted upon.

The attachments are of course not what they claim to be – the CDS message carries this; the Furniture Market message has this. Neither of these are things you want anywhere near your computer.

Messages like these cause two Problems:

Problem Number One is if a message like this was sent to, for example, your accounts department, would they consider it suspicious or would they open the (hostile) attachment without a second thought? After all, it seems legit – the usual red flags are mostly absent making the message more believable than most. However, if you go to the trouble of opening the attachment you’re running a definite risk of having your computer become part of a botnet, and at that point your real problems are only just beginning.

Problem Number One can be defended against in the usual ways:

  • Educate your users – keep them vigilant. A legitimate looking invoice would have better provenance if you’d actually placed an order with the company it claims to come from. Do you do business with the sender organisation, regardless of how authentic the message looks? Context is important!
  • Keep all your software patched and up to date
  • Run current anti-virus (although as usual there’s no guarantee of success here, judging by the VirusTotal links above)
  • Disable JavaScript in Adobe Reader
  • Don’t log into your computer with admin rights
  • etc!

Problem Number Two affects the sender of the message. Not the actual criminal who sent the message, but the organisation the message claims to be from. Here are some very recent scrapbook snippings from the websites of affected companies:





…and the list goes on. The unfortunate companies above have done absolutely nothing wrong – they’ve not been hacked, they’ve not lost their customer lists, nothing – yet they’ve been forced to put prominent messages like these on their websites, and their customer service staff are suddenly inundated with calls and emails. Under the circumstances, it’s just about the best thing they can do – it shows they care by reassuring their customers that nothing’s been compromised, and hopefully it’ll decrease the load on their service staff. But it’s still not an ideal thing to have to put on the company website.

Is there an effective defence against this kind of impersonation? Email, by its very nature, is insecure (it’s the Simple Mail Transfer Protocol, after all) – it’s trivial to make an email appear to be from anyone you like. Copying an organisation’s email template is just the icing on the cake.

You could employ one or more of the following techniques:

All of these are mechanisms which are designed to detect email spoofing, as in the above examples. A shortcoming of this approach is that it is the reciever’s responsibility to do the checking. If you’ve set up SPF, for example, it’s all for naught if the receiver doesn’t do the SPF check. Think about your own email arrangements – does your receiving mailserver perform SPF or DKIM checks?

Problem Number Two can therefore affect just about anybody, regardless of how careful you are in setting up anti-spoofing measures. The best defence against Problem Number One probably lies with the acutal human being opening the email – take the advice of these guys and ask the question, “Who Are You?”

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at

The MKII Robot Controller

Posted in Crazy Plans, Hardware on 29 January, 2014 by Alec Waters

I thought I’d briefly share the latest gadget I’ve been tinkering with. You may remember the robot I built for HackFu – I always thought I could do better with the packaging of the controller unit. It was in three pieces, namely the camera receiver, the TV, and the control unit itself:

wirelesscontrollerIn a fit of Wii U inspiration, I’ve managed to get all three components into a single, portable enclosure:


There’s a convenient carry handle on the top, handholds left and right, and you operate the sticks with your thumbs. The screen is one of those cheap TVs you get for use in your car.

The AV receiver’s antenna and tuning knob poke out behind one of the hand-holds. It doesn’t get in the way of your fingers, and the tuning knob has fortuitously ended up in a very convenient place:

botcontrollertunerThe antenna will fold through 180 degrees so it won’t catch on anything when you’re not using it. Next to the antenna is the secondary AV input for the display – by changing channels you can switch from the wireless camera feed to an external one. This means you can do things like hook up another Arduino with a Video Game shield and play Tetris:

botcontrollertetrisHere are some action shots showing the telemetry overlay and the bot itself, TempEx One:


botcontrollerandbotWith the lid off you can see the XBee for communicating with TempEx and the arrangement of the AV receiver and Arduino:

botcontrollertopoffThere’s a single 12v DC input jack in the bottom left that powers everything.

Things still on the TODO list include:

  • Swap the XBee for one that supports an external antenna. This will be mounted in the left hand hold, flipping up and down like the AV antenna does
  • Addition of a speaker for the camera audio
  • Find a compact 12v battery to remove the need for mains power (any suggestions?)
  • Spray it a suitably impressive colour :)

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at

I love it when a plan comes together

Posted in General Security, NSM on 9 January, 2014 by Alec Waters

As defenders, we have many reasons to do our jobs. We want to comply with regulations, protect our employers (and protect our pay cheques!), and just maybe we enjoy the challenge despite the certain knowledge that someday an exploit with our name on it is going to smack us between the eyes.

The “why we do it” is therefore straightforward; what about the “how”? How do we defend? I don’t mean from a technical perspective – at a generic level, what are we trying to achieve?

There are certainly many answers to that question, but I quite like the idea that there are three mutually supporting objectives for defenders. The idea I’m presenting below is probably a little monitoring-centric, but then so am I!

At the top tier, there’s the “Defenders’ Utopia”, namely Prevent-It:

planaIt doesn’t matter what “It” is – if we can prevent all badness, we’ve won! Let’s patch stuff, pentest stuff, educate our users, harden our deployments, use SDL principles and products X, Y and Z to prevent all the badness, guaranteeing us “corporate security hero” status.

Prevent-It is therefore our “Plan A”. Sadly, it’s not enough because Prevention Eventually Fails – we need a Plan B.

preventioneventuallyfailsIf we can’t Prevent-It, Plan B should be to “Detect-It” in a timely fashion:

planabAnd no, third-party breach notification doesn’t count as “timely”! As well as responding to obvious indicators such as AV or IDS hits, we need to be proactive in detection by hunting through all of the instrumentation at our disposal looking for indicators like uncommon or never-before-seen events, unusual volumes of network traffic or event types, Bob logging in from Antigua when you know he’s in Scotland, etc. A solid ability to Detect-It will help you invoke the Intruder’s Dilemma.

“Detect-It” is bigger than “Prevent-It” in the diagram because prevention is hard, and we are more likely to be able to detect things than we are to prevent them if we try hard enough. Attackers have more tactics at their disposal than defenders have preventative measures so you need to be as thorough and as business-tailored as you can be in your monitoring. Know your infrastructure in as much detail as possible in terms of the platform (e.g., MVC app on IIS8 behind a Cisco ASA) and make certain it’s behaving as expected. For a self-contained security team, this latter part might be hard – I’d possibly venture the opinion that an app’s functional spec might be a useful thing for the security team to have. Should app X be sending emails? Doing FTP transfers? Talking to SkyDrive? If the security team don’t understand these details, they may miss things.

Eventually, you’ll likely run up against an attacker who slips past detection and conjures up the defenders’ nightmare of third-party breach notification – you’ve been compromised, you didn’t notice it happen, and now you’re front page news. Plan B has failed – your final recourse is Plan C:


If we can’t Prevent-It, and we didn’t Detect-It then we have to maintain the ability to Investigate-It. This bit’s biggest because it represents your gathering of logs, network traffic data and other indicators – your monumental programme of “hay collection” (the Detect-It part can be thought of as a “hay removal” process whose output is needles, if you follow my metaphor).

Even boring, routine logs may be worth their weight in gold when Investigating-It – collect as much as is feasible and legal. Even if we don’t have the resource to actually look at all the collected logs as a matter of course, at least we’ve got a huge pool of evidence to trawl through as part of the Incident Response process.

We can also use Investigate-It for retrospective analysis. If a new set of IOCs (Indicators of Compromise) comes to light, we can check them against what we’ve collected so far. Investigate-It also supports your corporate forensic readiness plan – knowing what information you need as part of IR, where to get it, and what you can get quickly without outside help is key.

Stairway to Heaven

If our org has sufficient resources we can move back up the stack, leveraging each tier to improve the one above. If we have an excellent capability to Investigate-It, it means we can improve our ability to Detect-It by hunting through the collected logs in different ways, producing more insightful reports/alerts/dashboards that pull together many disparate log sources. Lessons learned as part of Investigate-It can be incorporated into Detect-It – make sure that the indicators that were missed this time won’t be missed next time.

Moving up again, improving our ability to Detect-It can improve our ability to Prevent-It because we may discover things we don’t like that we can put a stop to before they become a problem (e.g. people emailing confidential docs to their personal email account so they can “work on them from home”, people logging in as local admin, people running apps you don’t like, why is there an active Bluetooth serial port on the CEO’s MacBook, etc) or we may even discover Existing Badness that we can zap.

So now we’re back at the top of the diagram, hopefully in better stead than before we started. Like I say, it’s a monitoring-centric way of looking at things, but if you’re in the game hopefully it’s an interesting perspective!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at

When Worlds Collide

Posted in NSM on 8 November, 2013 by Alec Waters

ELSA is a powerful component of SecurityOnion; one can waste productively use many hours drilling through your logs. The more parsers and dashboards you write for your own specific log sources the more insightful it becomes and pretty soon you’ll be asking yourself questions you never knew you had.

Take the session below as an example:

elsa1This is Bro accounting for a TCP session, showing a local IP address (redacted) sending over 8MB of data to on TCP port 25289. Something like this should raise an eyebrow or two and is certainly worthy of further investigation – why is a local machine having this kind of conversation? Can we rule out foul play? Or is there an innocent explanation? Deerstalkers on, sleuths…

The first thing we can do is find out some more about the remote IP address. You can’t trust rDNS and whois to be totally accurate (or truthful), but a quick whois and dig -x tells us that we’re dealing with what looks like a residential broadband IP address rather than a business (the rDNS lookup is If it were a business with whom we have a relationship there may be an easier answer, but at the moment it looks like our local IP address is talking with a computer in someone’s living room. We still don’t know what the traffic was, though. Exfiltration of Top Secret business plans, maybe?

Maybe we can get some answers by pivoting from ELSA into capME to get a transcript of the session:

elsa2Drat. The plot thickens! Our local IP address has sent over 8MB of data to a computer apparently in someone’s living room, and we can’t tell what it is because it’s quite possibly encrypted. We still can’t rule out a leak of our Top Secret plans! What if is an innocent machine under the control of The Baddies who are using it to pillage all our stuff? Where’s my tinfoil hat?!

Unanswered questions bug me a great deal. Sometimes even NSM can lead you to a dead end. I can research as much as I like by using ELSA et al to look for other log entries that reference it, or by going OSINT crazy, but in this instance I’m all out of clues. What I’d ideally like to be able to do is work out which process on the local IP address made the connection – perhaps this would solve the mystery.

Marching over to the local machine (EnCase dongle in hand) with the intent of seizing it and carrying out a full host examination probably isn’t the most productive use of time. The user of the machine will hate me for stopping them from working, the process will take a long time, and even then it might not answer my questions fully. Not to mention the fact that I don’t have an EnCase licence in the first place.

Enter Carbon Black. I’ll leave it as an exercise to the reader to peruse their website, but suffice to say running Cb on your systems is akin to running process monitor all the time on all your machines, centrally collecting things like process execution trees, file/registry modification attempts, network connections, etc. It’s basically carrying out host-forensic tasks all the time, capturing very volatile events that you may not be able to recover in retrospect.

Did I just say it collected network connections? I wonder if we can ask it about

ELSA is a wonderfully extensible beast; amongst other things, you can write Plugins that can link to other systems to provide extra information based on ELSA searches. Carbon Black has a REST API and easily accessible search URLs – perhaps we can link ELSA and Cb together?

Happily, yes we can. We’ll get to the nuts and bolts of the plugin in a second, but the net result is something like this. By clicking on the “Info” link by our BRO_CONN log entry, we get a link into Carbon Black that will search on the dstip field:


Clicking on the Cb link will perform a search for the suspect IP address – provided our browser is logged in, we’ll see this:

elsa4Aha! It’s Spotify, which has a p2p-style protocol that makes use of “random” ports and encryption. According to the article, most of the music you listen to comes from other users’ machines – our mystery connection is likely the transfer of a song from one (local) Spotify user to another.

What we’re seeing above is a specific execution of Spotify, which means that all the events logged against it are those recorded at a specific time on a specific machine. Drilling down on the process, we can see:

elsa5…the process tree. We can see that explorer.exe started Spotify, and that Spotify itself has child processes. We can see that five other machines have the exact same version of Spotify on them, and that it’s a legitimately signed binary. If this were malware, being able to see at a glance how many other machines it’s executed on is a pretty handy thing. As it is, it’s not malware but we might like to speak to the users of the five machines in question if the use of Spotify represents a policy violation.

Searching the 3502 logged events for our suspect IP address:

elsa6…there it is. Drilling down onto the binary itself, we can see:

elsa7Note the convenient link to VirusTotal, and the Download link which you can use to investigate suspected malware in a sandbox.

To be able to go straight from a network-derived indicator to the process that caused it seems to me to be a pretty powerful ability!

Putting it into practice is fairly straightforward. Step one is to subclass the “Info” Perl class by creating /opt/elsa/web/lib/Info/ as follows:

package Info::Cb;
use Moose;
use Data::Dumper;
extends 'Info';

sub BUILD {
    my $self = shift;
    if ($self->conf->get('info/cb/url_templates')){
        foreach my $template (@{ $self->conf->get('info/cb/url_templates') } ){
            push @{ $self->urls }, sprintf($template, $self->data->{dstip});


The code above references configuration entries from /etc/elsa_web.conf. Add the following under “info” alongside the entries for “snort”, “url” and “windows”, altering the URL as appropriate for your Cb installation:

"cb": {
   "url_templates": [ "https://carbonblack/#search/cb.urlver=1&q=%s" ]

Finally, we need to tell ELSA which classes to apply the plugin to. Add the following under “plugins”:

"BRO_CONN": "Info::Cb"

That’s the lot. You might need to restart Apache, but once done you should be able to click “Info” on a BRO_CONN result and have a properly populated link into Cb, searching on BRO_CONN.dstip.

This is my first attempt to link ELSA and Cb, and it’s quite a basic one. ELSA also supports transforms to which results can be “piped” – examples that ship with the product include whois, dnsdb and cif. A Cb transform could perform more flexible queries, enriching an ELSA result set with supplementary information from Cb. Stay tuned; I’ll post again if I come up with something useful!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at

HackFu 2013 challenge teardown – Part Two

Posted in Crazy Plans, Packet Challenge on 24 September, 2013 by Alec Waters

Part One of this post is here; this time I’m going to talk about TempEx and its controller:


I for one welcome our new robot overlords


TempEx One! You muussst obeeeeeeyyyyy me!

Parts list

From the point of view of the challenge, TempEx is mostly chrome, but we all know that this is the element upon which all coolness is built and we should seek it out with ruthless determination. The core of TempEx is a DFRobotShop rover which is basically a stretched Arduino UNO with tracks and motors. The tracks, wheels and gearboxes are all standard Tamiya model parts, with custom brackets holding the whole lot to the mainboard. It’s a pretty nifty bit of kit, but it needs a bit more than the basic kit to be truly useful.

Firstly, it needs a bit more payload space; this is easily catered for with the expansion plate which sits above the mainboard on standoffs. This gives you considerably more space to work with:


There are plenty of cut outs that you can use to mount equipment, including holes specifically for mounting servos. In terms of payload, TempEx needed to carry an infra-red camera and a rangefinder on a steerable mount like this one from Dagu. Controlling servos with an Arduino is pretty straightforward in concept although surprisingly challenging to execute in an elegant fashion, but we’ll get on to that a bit later on.

The rangefinder is an HC-SR04, which can be had on eBay for a couple of pounds. It’s easy to use (even easier with a decent library) and pretty accurate for the price, although you need to get a good return “bounce” to get a reading – if you’re facing a surface at 45 degrees to the sensor you’re not likely to get a return at all.

I scored a cheap 900Mhz IR camera on eBay:


The camera can be driven from a 9v battery which gets drained pretty quickly, even more so when it’s dark and all the IR LEDs are turned on. To get around this I used lithium ones which when I tested them gave over five hours of service with no degradation in picture or signal, easily long enough to last through each team’s attempt at the challenge.

At this point, we’ve got enough gear to build a rover that you can drive around tethered via USB – not entirely practical. Two choices for wireless control are Bluetooth and ZigBee/XBee. I wanted to have a controller that worked without a PC so I went for the XBee option because it came with two radios, one for the rover and one to put in the controller.

Conceptually, control of the rover is straightforward. The ‘wasd’ sample is a useful base, reading a character from the serial port and operating the two motors accordingly:

int E1 = 6; //M1 Speed Control
int E2 = 5; //M2 Speed Control
int M1 = 8; //M1 Direction Control
int M2 = 7; //M2 Direction Control

void setup(void)
  int i;
  pinMode(i, OUTPUT);

void loop(void)
  while (Serial.available() < 1) {} // Wait until a character is received
  char val =;
  int leftspeed = 120; //255 is maximum speed
  int rightspeed = 120;
  switch(val) // Perform an action depending on the command
    case 'w'://Move Forward
    case 'W':
      forward (leftspeed,rightspeed);
    case 's'://Move Backwards
    case 'S':
      reverse (leftspeed,rightspeed);
    case 'a'://Turn Left
    case 'A':
      left (leftspeed,rightspeed);
    case 'd'://Turn Right
    case 'D':
      right (leftspeed,rightspeed);

void stop(void) //Stop

void forward(char a,char b)
  analogWrite (E1,a);
  analogWrite (E2,b);

void reverse (char a,char b)
  analogWrite (E1,a);
  analogWrite (E2,b);

void left (char a,char b)
  analogWrite (E1,a);
  analogWrite (E2,b);

void right (char a,char b)
  analogWrite (E1,a);
  analogWrite (E2,b);

I ended up with a nine-way control of q/w/e, a/s/d, and z/x/c using ‘s’ for stop and q, e, z, and c for large-radius turns running one track at full speed and the other somewhat slower. a and d were for zero-radius turns where the rover spins on the spot.

Moving from a USB tether to wireless via XBee was straightforward. Out of the box the XBee radios act as a kind of cable replacement – whatever one transmits the other receives. Leaving aside the security implications of this default config (and the hacker-rich environment in which TempEx had to operate) moving away from the tether starts by using the XBee to serial board that comes with the rover kit.


This appears to a PC as a serial port so you can just attach a terminal app to it and enter characters just like you would in the Arduino serial monitor window. The final step is to ditch the USB port altogether and use the serial TX/RX lines with a second Arduino, again just sending single characters for the rover to interpret.

There were a couple of gotchas along the way. Firstly, the rover would occasionally throw a track when turning, something that could be seen as a result of the sprocket wheels slowly moving outwards on their axles. I was a bit reluctant to glue these in place, but fortunately no tracks were shed during HackFu.

Secondly, I had trouble with power brownouts, especially when doing something like going from full forwards to full reverse. I made three changes to cater for this:

  • Moar axle grease! A tube of this comes with the gearbox for a very good reason.
  • I switched from using the 3.7v LiPo battery to the 4xAA holder. Using rechargeable NiMh AAs gave a voltage of between 5 and 6 volts, about double the nominal voltage of the included motors. The rover went like a rocket with the AAs driving these, but at a cost. Adam Borrell has done some testing with motors like these running under over-voltage conditions. I’m glad I read this before HackFu because the brushes can wear out in a matter of hours – after all of the development hours TempEx had on the clock there was a distinct possibility that the motors would fail during the event. I replaced the 3v motors with 6v ones, and made sure I had spares on the day.
  • Finally, I re-wrote the code to be a little kinder on the drivetrain. Instead of slamming the motors from zero to max revolutions in one hit, I gently ramped the RPMs up so that it took about half a second to get to top speed.

Operating the pan/tilt rig was done in a similar way to the motors, using r/t/y, f/g/h and v/b/n, with t being down, f for left, r for down/left etc. g centred the rig forwards. Similar “kind” code was written for the servos – if slamming a motor from zero to max is unkind, doing the same with a servo is plain brutal! With the mass of the camera to shift as well as the rig itself, it’s important that the servo take its time to reach the desired rotation. For each pass through the Arduino’s loop() the servo would ask “have I rotated far enough yet?” and if not it shifted another couple of degrees towards the goal.

Here is some sample code that moves a servo “kindly” under the command of a Wii Nunchuk to illustrate:

#include <Servo.h> 
#include <Wire.h>
#include <ArduinoNunchuk.h>

#define BAUDRATE 19200

ArduinoNunchuk nunchuk = ArduinoNunchuk();
Servo myservo;  // create servo object to control a servo 
int potpin = 0;  // analog pin used to connect the potentiometer
int val;    // variable to read the value from the nunchuck
int servopos; // where the servo is
int threshold = 8; // trigger for movement

void setup()
  servopos = map(nunchuk.analogX, 25, 221, 0, 179);     // Get initial value
  // SERVO
  myservo.write(servopos);  // initialise position
void loop() 

  val = map(nunchuk.analogX, 25, 221, 0, 179);     // scale it to use it with the servo (value between 0 and 180) 

  Serial.print(nunchuk.analogX, DEC);
  Serial.print(' ');
  Serial.print(' ');
  Serial.print(' ');  

  if( ( servopos < val ) && ( val - servopos > threshold ) )
    // Moving to the right
    servopos += int( threshold / 2 );
  else if( ( servopos > val ) && ( servopos - val > threshold )  )
    // Moving to the left
    servopos -= int( threshold / 2 );
    // Not moving!
  if( servopos < 0 )
    servopos = 0;
  else if (servopos > 179 )
    servopos = 179;
  myservo.write(servopos);                  // sets the servo position according to the scaled value 
  delay(10);                           // waits for the servo to get there 

It just goes to show, it ain’t what you do, it’s the way that you do it:

Moving swiftly on…

…to the controller. There are four bits to this:

  • An Arduino Uno
  • An XBee radio sitting on the aforementioned USB adapter hooked up to the Arduino’s serial port
  • A pair of two-axis potentiometers, one for controlling the rover and one for steering the pan/tilt rig
  • A Nootropic Design Video Experimenter board, a bundle of awesome if ever there was one. The output of the camera receiver plugs into the video input, with a TV on the video out

The whole lot fit quite nicely into an OKW enclosure that I had left over from the now-defunct WiFi project (a fully-routed mesh wireless network on Brighton beach for public use – ten years ago!).

The mode of operation is as follows:

  • Read the x and y values from the two sticks and convert them to the wasd-style character
  • Send the character to TempEx by printing it to the serial port, which sends it to the XBee, which sends it to the other XBee on TempEx where the rover’s code takes over
  • TempEx acts on the received character and takes a reading from the rangefinder. This is sent back to the controller via the XBees
  • Back on the controller, read the range from the serial port and use the Video Experimenter board to overlay it on the TV feed from the camera
  • Repeat :)

Step one was an interesting coding challenge – converting a pair of 0-to-255 values to a quadrant in a 3×3 grid in an elegant and efficient manner. I don’t want to blab my method here because I want to use it as a teaching case in the Arduino workshops I’ll be running soon. If you want a hint, contact me via Twitter and I’ll give you a nudge in the right direction.

The VE board displayed a bit more than just the range – I wanted it to look a bit like a heads up display in a military aircraft:

Tower, this is Ghostrider requesting a flyby

The Pan/Tilt markers have indicators that show in which direction you’re steering the camera, the L/R indicator shows which direction the two tracks are moving in, the range is at the bottom, comm errors are shown at the top, and the targeting reticle in the middle is there to make you feel extra-menacing. Here’s a less-than-clear shot of it in action at HackFu:


The VE’s overlay was a little light but perfectly legible despite what the picture above looks like. I found that by feeding the camera receiver into a VCR and attaching the VCR to the VE board produced better results, showing that the problem is more likely the output of the camera transmitter rather than the VE board.

I wanted to cater for the case where comms with TempEx were interrupted due to interference or excessive range, so in an attempt to implement reliable control the following steps were taken:

  • If neither joystick is deflected from its home position the controller continually sends ‘s’ (stop) to TempEx. If the controller gets a range in return it knows that TempEx is still there. If we don’t get anything back for two seconds, display NO COMM on the HUD to let the user know.
  • When a joystick is moved, continually send the indicated character to TempEx. This means that, moving or not, TempEx is expecting to receive something from the controller all the time. If TempEx doesn’t hear anything for two seconds it will stop both tracks and centre the pan/tilt rig.

This means that you can never have the case where TempEx runs off out of control if the wireless comm breaks down (it doesn’t stop teams from hitting obstacles at oblique angles and tipping TempEx over, but that’s another story!)

So there you have it, TempEx and its controller. I had a ton of fun putting the challenge together, and I think people had fun playing it. As I’ve said, HackFu is beyond awesome – keep your ear to the ground sometime next Spring here, here and here for a chance to win a ticket for HackFu 2014. Maybe see you there!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at


Get every new post delivered to your Inbox.

Join 35 other followers