Category: Capture the Flag

Hey all!

My husband’s company recently did an internal (commercial) CTF, and as a CTF nerd I got suckered into helping him. I thought one of the challenges had a pretty interesting solution - at least, something I hadn’t done before - and I thought I’d do a little write-up!

Because it’s a commercial CTF, I wrote my own vulnerability binary, which you can grab here. It’s much, much simpler, but has all the components I wanted. They also provided libc.so, but since I’m not actually running the challenge, you can just use your own copy.

(Note that I’m running the BSidesSF CTF again this spring, and will probably gussy up this challenge a bit and throw it in - don’t let a good challenge go unwasted!)

This is a write-up for turing-complete, turing-incomplete, and turing-incomplete64 from the BSides San Francisco 2024 CTF!

turing-complete is a 101-level reversing challenge, and turing-incomplete is a much more difficult exploitation challenge with a very similar structure. turing-incomplete64 is a 64-bit version of turing-incomplete, which isn’t necessarily harder, but is different.

Let’s look at the levels!

Slay the Spider is a Minesweeper-like game where the user and computer try to uncover a spider. The challenge name and trappings are based on Slay the Spire, which is one of my favourite games.

This is a write-up for Safer Streets. I apparently wrote this in more “note to self” style, not blog style, so enjoy!

No Tools is a fairly simple terminal challenge, something for new players to chew on.

I suspect there are several different ways to solve it, but the basic idea is to read a file using only built-in functions from sh.

The premise of the three challenges cant-give-in, cant-give-in-secure, and cant-give-in-securer are to learn how to exploit and debug compiled code that’s loaded as a CGI module. You might think that’s unlikely, but a surprising number of enterprise applications (usually hardware stuff - firewalls, network “security” appliances, stuff like that) is powered by CGI scripts. You never know!

This challenge was inspired by one of my co-workers at GreyNoise asking how to debug a CGI script. I thought it’d be cool to make a multi-challenge series in case others didn’t know!

This write-up is intended to be fairly detailed, to help new players understand their first stack overflow!

too-latte is a challenge I wrote based on CVE-2023-0669, which is an unsafe deserialization vulnerability in Fortra’s GoAnywhere MFT software. I modeled all the vulnerable code off, as much as I could, that codebase. It’s obviously themed quite differently.

ROP Petting Zoo is a challenge designed to teach the principles of return-oriented programming. It’s mostly written in Javascript, with a backend powered by a Ruby web server, along with a tool I wrote called Mandrake. Source code is shared between the three parts of the challenge, and is available here.

Overflow is a straight-forward buffer overflow challenge that I copied from the Hacking: Art of Exploitation examples CD. I just added a flag. Full source is here.

id-me is a challenge I wrote to teach people how to determine file types without extensions. My intent was to use the file command, but other solutions are absolutely possible!

This is a write-up for three challenges:

• getout1-warmup
• getout2-gettoken
• getout3-apply

They are somewhat difficult challenges where the player reverses a network protocol, finds an authentication bypass, and performs a stack overflow to ultimately get code execution. It also has a bit of thematic / story to it!

This is a write-up for flat-white and flat-white-extra-shot, which are easier Java reverse engineering challenges.

Hey folks,

This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!

Hey folks,

This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!

Hey folks,

This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!

Hey folks,

This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!

This is a video walkthrough of Log ‘em All, a difficult Hacking / Reverse Engineering challenge based on a classic bug in Pokemon Red. You can view the video below, or directly on Youtube.

I’ve never done a video-based writeup before, so I’d love feedback!

Hi Everybody!

This is going to be a challenge-author writeup for the Glitter Printer challenge from BSides San Francisco 2021.

First, a bit of history: the original idea I had behind Glitter Printer was to make a video game challenge involving cartridge-swap, where I’d write a handful of simple video games in 100% x86 code with no imports or anything (like an old fashioned cartridge game), and the player could swap between them without memory being re-initialized. Folks used to do this sorta thing on NES, and maybe I’ll use it in a future challenge, but I decided to make this a bit simpler.

While experimenting with writing libraries without libc, I realized just how much work it was going to be to write a bunch of games, and decided to simplify. My next ide was to write a “driver” type thing, where a blob of code is loaded into +RWX memory and the player could go wild on it. The the name Glitter Printer came across my radar, I don’t even remember why, and that gave me the idea to do an LPR server.

That’s quite the background!

Hi Everybody!

This is going to be a challenge-author writeup for the Secure Asset Manager challenge from BSides San Francisco 2021.

It’s designed to be a sort of “server management software”. I sort of chose that theme to play off the Solarwinds thing, the theme wasn’t super linked to the challenge.

The challenge was to analyze and reverse engineer a piece of client-side software that “checks in” with a server. For the check-in, the client is required to “validate” itself. The server sends a random “challenge” - which is actually a block of randomized x86 code - and that code used to checksum active memory to prevent tampering. If anybody reading this worked on bots for the original Starcraft (and other Battle.net games), this might seem familiar! It’s based on Battle.net’s CheckRevision code.

Hi Everybody!

This is going to be a challenge-author writeup for the Hangman Battle Royale challenge from BSides San Francisco 2021.

This is actually a reasonable simple challenge, overall. I got the idea of using a bad mt19937 implementation (the Mersenne Twister PRNG used by Ruby and Python) from SANS Holiday Hack Challenge 2020 (which is still online if you want to play!), and wanted to build a challenge around it. I had the idea of Battleship originally, but ended up deciding on Hangman for reasons I no longer remember, but that I’m sure made sense at the time.

This is going to be a writeup for the Reverseme challenges (reverseme and reverseme2 from BSides San Francisco 2021.

Both parts are reasonably simple reverse engineering challenges. I provide the compiled binaries to the player (you can find those in the respective distfiles/ folders), and you have to figure out what to do with them.

Both challenges use the same basic code as the runme challenges, where you send shellcode that is executed. Only in this case, the shellcode must be modified or “encoded” in some way first!

Hi Everybody!

This is going to be a writeup for the Runme suite of challenges from BSides San Francisco 2021.

The three challenges I’ll cover are runme, runme2, and runme3, which are increasingly difficult write-shellcode challenges. As always, the binary and info the player gets is in the respective distfiles/ folder, and source is in challenge/.

Thanks to symmetric (aka Brandon Enright) for this wonderful guest post! I tried to proofread it, but holy math Batman!! –Ron / @iagox86

Hey all, this is symmetric here! I was thrilled to be once again involved in running the BSidesSF CTF with such creative teammates and skilled CTF players.

My favorite challenge this year was rsa-debugger which, despite getting 12 solves, was actually quite hard. In this post I’d like to tell you a bit about the genesis of the challenge and how to solve it.

For my third and final blog post about the BSidesSF CTF, I wanted to cover the solution to Chameleon. Chameleon is loosely based on a KringleCon challenge I wrote (video guide), which is loosely based on a real-world penetration test from a long time ago. Except that Chameleon is much, much harder than either.

As mentioned in a previous post, I was honoured to once again help run BSidesSF CTF!

This is going to be a quick writeup for three challenges: config-me, rusty1, and rusty2. All three are reversing challenges written in Rust, although the actual amount of reversing required is low for the first two.

Once again, it was my distinct privilege to be a BSidesSF CTF organizer! As somebody who played CTFs for years, it really means a lot to me to organize one, and watch folks struggle through our challenges. And more importantly, each person that comes up to us and either thanks us or tells us they learned something is a huge bonus!

But this week, I want to post writeups for some of the challenges I wrote. I’m starting with my favourite - Gman!

Hey all,

This is going to be an author’s writeup of the BSidesSF 2019 CTF challenge: genius!

genius is probably my favourite challenge from the year, and I’m thrilled that it was solved by 6 teams! It was inspired by a few other challenges I wrote in the past, including Nibbler. You can grab the sourcecode, solution, and everything needed to run it yourself on our Github release!

It is actually implemented as a pair of programs: loader and genius. I only provide the binaries to the players, so it’s up to the player to reverse engineer them. Fortunately, for this writeup, we’ll have source to reference as needed!

Hey everybody,

A couple months ago, we ran BSides San Francisco CTF. It was fun, and I posted blogs about it at the time, but I wanted to do a late writeup for the level b-64-b-tuff.

The challenge was to write base64-compatible shellcode. There’s an easy solution - using an alphanumeric encoder - but what’s the fun in that? (also, I didn’t think of it :) ). I’m going to cover base64, but these exact same principles apply to alphanumeric - there’s absolutely on reason you couldn’t change the SET variable in my examples and generate alphanumeric shellcode.

In this post, we’re going to write a base64 decoder stub by hand, which encodes some super simple shellcode. I’ll also post a link to a tool I wrote to automate this.

I can’t promise that this is the best, or the easiest, or even a sane way to do this. I came up with this process all by myself, but I have to imagine that the generally available encoders do basically the same thing. :)

Welcome!

While this is technically a CTF writeup, like I frequently do, this one is going to be a bit backwards: this is for a CTF I ran, instead of one I played! I’ve gotta say, it’s been a little while since I played in a CTF, but I had a really good time running the BSidesSF CTF! I just wanted to thank the other organizers - in alphabetical order - @bmenrigh, @cornflakesavage, @itsc0rg1, and @matir. I couldn’t have done it without you folks!

BSidesSF CTF was a capture-the-flag challenge that ran in parallel with BSides San Francisco. It was designed to be easy/intermediate level, but we definitely had a few hair-pulling challenges.