Primary Menu

Author: scriptmonkey

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.

Binaries

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.

Ask the Chef

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.

Loading…Triggering…

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.

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.

‘Leakkey’

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.

This matches our format on a line basis

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 ;).

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”.

Like this:

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).

Share this:

Like this:

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.

First, plug in the usb key you intend to burn the image to into the laptop.

Not all my USB keys worked, I had more success with USB2.0 usb keys vs USB3.0 supporting ones.

Bounce the box and get into the bios.

Navigate to where you can specify the boot order.

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!

Set the order such that the USB will boot first in the list.

Set the bios boot support to both (not UEFI only, we’re going legacy mode here just to get the damn thing to boot).

Download the lenovo update image available from the lenovo support website.

Get your usb key into your windows VM.

Using YUMI MBL, select the option to “boot unlisted iso (GRUB)” and tick “format fat32” then select the lenovo iso.

Click next, etc… and wait for the usb key to be created.

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!

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…

Like this:

Intro

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.