EMFCTF – Electromagnetic Field CTF Write-Up 2018

So it’s come around once again, EMFCamp is an event held every 2 years somewhere in the UK (usually south of England as far as i’m aware) where people from all walks of life come together to celebrate anything that’s geeky/nerdy or just plain cool!

If you get to go, expect LEDs, Lasers, algorithmically/AI generated techno music, retro gaming consoles. Cool vehicles, crazy constructions, human hacking, blacksmithing, clothes making, recycling t-shirts into cushions… you name it, it’s probably available at the camp. It takes place over a 4 day period (arrive Friday, leave Monday) and is welcoming to all.

I’ve been back in 2016 on my own and managed to make friends with the EMFHam group a few days before I went to have a place to pitch my tent and some people with similar interests to go and hang with in their village. I loved it! it was absolutely brilliant. This year, I neglected to plan ahead and didn’t book off the required leave so couldn’t go in person.

But… the EMFCTF was running and accepting remote applicants so about 6pm on Friday night as I’m about to pack up after a clinic day in work (we do internal conferences three times a quarter) I realise this, quickly register a team as an individual participant (Team: Solomonkey) and get involved.

After a brief twitter interaction to get an account activated (I needed a flag you could only acquire if you were on-site) I was on my way.

Know Your Packets

I’m not going to write these up as it was a pretty easy series of challenges. Most of the issue came from having to interpret what you were seeing to determine the flag. I did like the spam transfer service and the brain melter however, they were fun challenges to figure out, a little bash scripting was required too 🙂

Crack Me

Again, pretty simple series of challenges the one that caused me the most hassle was the one that required film trivia knowledge, I took the hint and still didn’t get it for an entire 12 hours due to a capitalisation issue with my flag submission. I think I pretty much submitted almost the entire script of the movie by the end of it.


Here’s where the write ups start. Only 3 as I never did get the 4th one before the scoring time of the CTF ended.

Diff me if you can – 10 points

Two files were provided, diff-me-if-you-can-1 & 2.

I don’t generally do much ELF reverse engineering or debugging so I was already on the back foot. My first port of call with any binary is a quick grep/strings of the thing.

In this case the binary is rather small and this is a quick process.

$strings diff-me-if-you-can-{1,2}

Very quickly a few things drop out that are of interest within the second binary.

Interesting strings

From the above I can guess that the program is doing something to “decode” the actual flag, but lets go deeper…

Downloading ida-free7.0 and running it against the binary to view the disassembly and execution flow reveals a few more things. We find the f14g constant and use ida’s “list cross-references” to identify the function within the program that utilises it.

Ida – “List Cross References To”

Bingo. getspnam is our friend.

Classic loop structure

Looking at the tree view for the function we can see a few things, but from a zoomed out perspective we can guesstimate that the following is happening.

  • There is some setup where the memory address for the encoded flag is loaded into a register.
  • A call to strlen is performed, which returns the string length into a register
  • A comparison takes place between some register and the one holding the length of the string
  • Depending on that comparison it either loops again or it returns from the function call.

Just from my layman’s understanding of the code here I’m assuming that some operation is done to every single character of the flag and sure enough if we look closer at the left hand branch of the loop we can see an instruction to perform a bitwise xor operation against two registers.

Okay I think we can solve this at this point. We know that:

  • There is an encoded string called F14g.
  • The contents of which are: `jga}q66rq66r’~it’acruvhgk{
  • This is used in a subroutine that performs a bitwise xor against it.

Ask the Chef

So one tool you’ll see me use a lot here is ‘Cyberchef’ an open-source JavaScript data manipulation tool release by GCHQ: https://cyberchef.gchq.github.io

It’s an awesome tool for data manipulation and I use it regularly with work.

One of the functions it has is a XOR brute force feature so lets give that a go!

Challenge Completed! – 10 points to SoloMonkey

Et voila! The flag is revealed.

Reverse Brute – 30 points

Lets move onto a 30 pointer, bit of a jump from the previous but lets go.

We’re provided with a single file this time, a .so this file extension denotes a shared library, similar (in layman’s terms once again) to a DLL in windows parlance it contains resources and functions that can be called upon by other executables… but we don’t have any.

First step as always was strings, sadly no dice for a flag but it did reveal a few interesting phrases surrounding namely: “leakkey” and “keystring”.

We’re going to have to do something clever with this one. The clue from the CTF web dashboard was “load, locate and trigger the leak”. In my head this means that we’ve got to somehow load the shared library, locate the leaky function and cause it to fire.


Lets solve the loading issue first. I initially fell into a rabbit hole of trying to write my own C program to do this, but having never really written C in anger, at least not in the last decade and not being familiar with calling shared libraries either, this was a wasted effort.

Then I recalled something from a python training course many years ago where we were calling functions from win32 dll’s within python. A quick google reveals the ctypes library is just the ticket and a nice and easy bit of code snippet is given for calling functions in an external shared library on linux.

#!/usr/bin/env python
from ctypes import *
rb = CDLL("./reverse-brute-2.so")

is all that’s needed.

Running the above inside of a python interactive terminal results in:

Output! WOOT!

Okay we’ve got ourselves some data. So I headed off to my favourite data manipulation tool once again and attempted to solve the issue. Only right from the off my spider senses should have been tingling, these aren’t anywhere near printable ascii characters (some are unicode printable, but nothing meaningful) and many hours and failed flag submissions later, we’re no closer to finding the issue.

Back to the Code

Lets fire up IDA one more time and have a look at what’s inside.


So we see the ‘leakkey’ function listed on the side and if we view that in tree view once again we’re seeing this classic loop structure. Applying the same reviewing steps we can see the following happening:

  • Some setup occurs where the string length of a constant referred to by “keystring_ptr” is taken.
  • This is used in a comparison to determine whether or not to loop.
  • If its not equal, it performs several operations to it
    • calls _rand
    • appears to use static values of ‘80808081h’ and ‘1Fh’ for something
    • shift left 8 bits – Just from using my head I’m assuming this is iterating through each character/byte in a string/array.
    • calls _getuid – I initially miss this.
    • performs some xor operations,  twice over.
    • calls fprintf to print out that particular byte.
    • adds 1 to the counter and loops.
  • If it is equal, it returns to the function that calls it.

So I spend several hours trying to figure this out and getting nowhere (including writing the whole subroutine out on an A4 piece of paper and trying to paper debug what was going on) when I recalled a video by @liveoverflow where he shared some info relating to common tools such as objdump, strace, radare2 and hopper. I remember hopper having a feature of producing pseudocode from the assembly and hopefully making the assembler much easier to read.

Easier to read

So from the above we can now see clear as day, the output relies upon the UID that the parent process is running as. I’d been missing this call all along, or just dismissing it as not having any effect. Argh! *much facedesking occurred at this point*.

Linux has very few iconic “UIDs” the most obvious of which is UID 0 for root, but 500 (red hat) and 1000 (Debian) are both also well known for the traditional start of the user space UIDs. We’ll assume its UID 0 as that’s ubiquitous across all *nix systems.

Easiest way of doing this is just running the thing as root so we do just that.

Different Data!

Given the different data we’ve now got we’re onto a winner it seems and these characters, are all ascii printable!

Another challenge solved!

Flag obtained!

Space Invaders – 40 Points

Okay we’re on a roll, well it seems like it from reading the blog post but in reality we’re down to the final few hours of the CTF and I’ve been pulling my hair out for most of it 🙂

Lets move onto challenge 3. We’re given a single file called “spaceinvaders.hex” and the clue is “this one is weird – what the hell does it run on for a start”.

So we open the file. It looks odd. Sort of like a hex-dump file but not quite. The colon is in the wrong place, there’s no spacing and the memory addresses (or what I’m assuming to be addresses given its just all smudged together with the data) appear different to what I’d expect.

wtf is this?

So I have to admit, initially I thought it was just a malformed file and I tried reformatting things and altering it using sed/awk to make it more “hex-dump” like, I got bored and frustrated with no real success and decided to wing it.

Lets google: “hex file starting with :”

Oh… interesting.

So a click or two later and reading the documentation I see a few things.

  1. This matches our format on a line basis
  2. The file ending ends as stated in it too

I think we’ve found our file-type. Now how to deal with it. Reading the above web page and just under the section that accurately describes our EOF signature/magic number, there is a link that discusses “Converting HEX, Binary, etc file formats”: http://www.keil.com/support/docs/4038.htm

Reading through it talks of windows executables but also of a linux package available from sourceforge called “srecord” a brief apt search comes up trumps and there is already a package in the ubuntu repositories for srecord!

SRecord found in Ubuntu Repository!

A brief install and we’re left with a few executables that are preceded with the prefix “srec_”.

One of these “srec_cat” appears to be used for concatenating Intel hex files together, only by default it seems to be configured for a Motorola EEPROM format, we don’t want that. We want Intel format.

After scouring through the man file for a bit, and a little trial and error, the line we’re after is:

srec_cat space-invaders.hex -intel -output space-invaders.bin -binary

Now with a binary file, we can go back to our default mode of handling binary reversing, lets use GREP! – What? you were expecting strings?, well Grep does support binary files and now after submitting flags previously we definitely know the flag format, it saves us having to scroll through a bunch of string output 😉

grep -io --text flag{.*} space-invaders.bin
Take that evil aliens! 🙂

And that’s the final flag we managed to obtain for the binary challenges.

The End?…

So no. There was one more challenge called Das Uboot remaining in the binary pile and I failed to beat it, in the end only a single team “Never Try” actually did solve it. I still have the flash.bin here and I should in theory be able to solve the challenge so I’ll keep plugging away and maybe someday I’ll post how to do that one too.

Sploity challenges? Nope, I had a quick look at them but they came up right at the end of the last day and I got nowhere, given they are remote network services, I probably won’t get to write those up and hope to read write ups from the teams that did: GraceHoppersPosse and Never Try.

One thing I am relatively sure of is that I probably didn’t solve any of these challenges in the intended manner. I approached it from the perspective of someone unfamiliar with the use of debuggers and reverse engineering on Linux and got lucky.

Ultimately in a CTF, the journey doesn’t matter the destination does. What I can tell you is that these few lines of solution do not include the HOURS and HOURS spent smashing my face against them. I spent most of the 3 days trying to solve these and I learned a hell of a lot in the process and that’s what this is to me. An opportunity to educate myself and practice topics I generally don’t make use of in my typical workload.

How do I think I did?

So its difficult to judge, I was doing stuff in this challenge that I’ve not really played with before I’ve learned a hell of a lot about interrogating binaries on Linux and my wireshark-fu is through the roof after completing all the “know your packet” challenges.

I was also just one man against teams where multiple people were in play. I ultimately finished 5th overall after being pipped to the post for fourth by Team LB in the final hours of play.

Additionally, these teams were all on-site and able to compete for the 237 marks up for grabs in the scavenger hunt. There were several times when I wished I was on-site during my downtime so I could go for a walk and still score 3 points for each scav hunt flag I completed.

If you look at the breakdown between myself and the 4th place finishers Team LB it becomes more evident how much I lost out by not being on-site. Lesson Learned – ALWAYS buy tickets for EMFCamp ;).

Only off-site challenge points obtained (aside from account activation flag)
~80% of their score from Scav Hunt flags

Despite all the above however, I learned a hell of a lot from this CTF and would highly rate it for anyone to have a go, it was great fun to participate in and I’ll definitely be back again next year, this time hopefully alongside a team of people and being able to participate in the on-site challenges.

“Award Points”

Ugh!!! So I took the hits with hints in this CTF. Very often I’d get to the end of a challenge and still not be able to submit a valid flag and I’d take the hint. In every single case except 1 (the film trivia crack) the hints given were of no use to me given where I was in the challenges. It’s a chance and decision you have to take/make on a coinflip but I basically threw away 21% of my score to hint penalties which I really shouldn’t have taken.

Follow up videos…

I have a bunch of recorded videos of me solving the above challenges that I intend to edit and post up on YouTube. I’ve narrated them via voice over so you can sort of see my thought process throughout. These will be getting uploaded “soon”.

Thanks to the organisers of @emfctf who I believe are a team from Cisco Security, what once was Portcullis/Portcullis Labs.

Cool things you need to check out

LiveOverflow – This person regularly posts “how-to” videos for reversing, crack-mes, ctf challenges. I’ve learned basically almost all the techniques I performed above thanks to their videos.

https://www.hackthebox.eu – awesome hacking challenges and VMs perfect for practising your skillz 😉



Quick noddy breakout tip using Favourites

I did another Citrix breakout job just the other day and as per usual found the effectively cosmetic only lockdown provided for by group policy… remember kids: “Group Policy is not a security boundary”.

So I had a bit more of a play about imagining I had less access than I did. Turns out that while file paths and calls were correctly disabled within the address bar of internet explorer, I could quite happily specify them as a link within the favourites bar by modifying a pre-existing favourite and then clicking it.

“Right click, add toolbar, links”
Why on earth does this method work if paths are disabled in IE?!

Clicking the abused favourite link would then pop explorer (or tbh anything you like, its effectively a .lnk at this point).

Yes… classic armadillo security – Crunchy on the outside, gooey on the inside. #DimeBar

Not world-destroying by any means but yet another method of breakout worth considering. Not sure why i’ve not used this before now but meh, its one to remember for next time 🙂

Updating the Thinkpad X220 Bios…

So this is more for my notes and I suppose to save anyone else out there the pain i’ve just gone through for the last few hours trying to upgrade my v1.20 bios to the latest 1.44.

So I followed endless guides after failing a few times myself and nothing seemed to work. Grub image booting was the closest but in that mode while it successfully booted the update tool, it disabled the onboard keyboard and no external usb keyboard I had available would work either.

You will need for this:

  • Windows VM
  • Yumi MBL (the stable version worked fine for me, didn’t need the UEFI beta)
  • A suitable usb key that is seen by your thinkpad within the BIOS.
  1. First, plug in the usb key you intend to burn the image to into the laptop.
  2. Not all my USB keys worked, I had more success with USB2.0 usb keys vs USB3.0 supporting ones.
  3. Bounce the box and get into the bios.
  4. Navigate to where you can specify the boot order.
  5. Look for the label of your USB drive showing next to USB HDD. If its not there, you’re going to need another key. If it is continue!
  6. Set the order such that the USB will boot first in the list.
  7. Set the bios boot support to both (not UEFI only, we’re going legacy mode here just to get the damn thing to boot).
  8. bounce the box and boot into your OS.
  9. Fire up your windows VM. Download YUMI Multiboot linux executable to disk.
  10. Download the lenovo update image available from the lenovo support website.
  11. Get your usb key into your windows VM.
  12. Using YUMI MBL, select the option to “boot unlisted iso (GRUB)” and tick “format fat32” then select the lenovo iso.
  13. Click next, etc… and wait for the usb key to be created.
  14. When created, reboot your host, leave the usb key where it is it’ll hopefully (providing you’ve set up the boot order correctly) boot up just fine on its own.

YUMI will boot and offer you a grub menu, select “boot unlisted iso” and select the lenovo iso from the list.

This will finally get the iso booted and crucially you’ll have a keyboard that works. Check it with a quick f1 before you go any further, if it doesn’t work you’re on your own. I spent like 6 hours trying different combinations to get this damn thing updated.

Select option 2 to start the upgrade process, accept the warnings and wait a while. It’ll warn you and offer you the opportunity to “do not remove the cd or remove the cd”. Pull the usb drive at that point and hit enter.

Your Thinkpad will reboot, you’ll see a message saying “updating electronic control program” or words to that effect for a short period of time before another reboot and it booting into your original hdd os.

Reboot once again and smash that thinkvantage button (if thinkvantage button doesnt appear to be working, alternate smashing the f1 button too) to get back into the bios check the version numbers, they should now be updated. Go back through where you’ve screwed with your boot order and UEFI support and set them all back to where you want them and you’re done!

Grab a cuppa, stick your feet up and chill, you’re done!

Control Panel Funtimes – Basic but worthy of note

Accessing control panel applets via control.exe and rundll32 or just directly calling the .cpl, like ncpa.cpl to access network settings is not new.

I find myself often referring to a friend’s blog over here: https://www.attackdebris.com/?p=143

Where he breaks out some of the other tools that are always handy on a breakout job, the amount of times that the dsquery line has come in handy on everything from breakouts to redteam engagements is insane.

What is new however is me losing my damn notes file on them, thankfully it seems Microsoft has published their own notes so for those of us with rubbish memories…

Here you go: https://support.microsoft.com/en-us/help/192806/how-to-run-control-panel-tools-by-typing-a-command

Key bit: “rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl”.

Oh and another golden oldie while we’re at it, introducing Godmode a feature that’s existed for bloody yonks…

  • Create a folder
  • name it: GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}
  • Open it.

See shortcuts to every control panel option your account should have access to.

Using your Intel Integrated GPU with Hashcat


I recently put together a presentation for work to try and instil some more intelligence into folks hashcracking attempts beyond just throwing the largest dictionary possible with a massive ruleset against it and calling it done.

As part of that talk I raised the point that installing the Intel OpenCL runtimes for your CPU doesn’t have to be the be all and end all. If you don’t mind a bit of kernel module compilation, you can also have your intel hd graphics do the heavy lifting and you’ll notice some performance gains above your CPU.

Supported driver configurations for hashcat v4.0.1

I last did this a year or two ago and it was incredibly mandraulic and painful, but it turns out there is now a script (or i just plain missed it the first time around) available by intel that providing you’re using one of their “supported” platforms you can run and it’ll handle the dependency hell and installation of the custom kernel.

You should note, Hashcat considers the intel gpu runtime to be broken and while booted into the 4.7 kernel I don’t appear to be able to force the selection of my CPU for cracking, though it is listed as an opencl device so whether you still want to go ahead with this is up to you.

Getting Started

First, I suggest reading through stuff on: https://software.intel.com/en-us/articles/opencl-drivers#latest_linux_driver

Then you need the installation script: https://software.intel.com/file/555660/download%20Edit

I’m assuming you’re running ubuntu 16.04 LTS as that’s what I have here, you can confirm this with a cat /etc/lsb-release. It should come out like mine:

Pre-Requisites – Ubuntu 16.04

Warning: The next stage on an intel i7 5600u took just over an hour to complete. Ensure your laptop is plugged into the mains and you’ve got the time to wait in order to compile the kernel.

Do a apt full-upgrade and a reboot before starting, then just call the script.

sudo ~/Downloads/install_OCL_driver.sh install

Accept the warning if you’re ready to proceed

Then wait…

Reminds me of the XKCD cartoon “Compiling”

An hour later you should get:

All completed, just need a reboot

Quick Reboot, select the 4.7 kernel in grub and you’re finished! Nice and easy.

Performance comparison

So this isn’t a definitive sample obviously but here is a comparison between the same benchmark run on CPU vs GPU.

WPA2 Performance using Laptop CPU
WPA2 Performance using Laptop Intel GPU

So a nice 50-ish% gain in performance. Not quite as high as I seem to remember when I first did this but my memory has been rotted by far too much beer consumption and times change.

Happy Cracking!