Build It Break Fix It

These past few weeks, we participated in Build it Break it Fix it. Our team consisted of Ancat, Blankwall, ColdHeat and Kiwi. Contestants were tasked with writing correct, secure and fast code in the Build it round. Next, the Break it round has them looking for bugs and vulnerabilities in other teams’ submissions. Finally, the Fix it round allows teams to unify bugs submissions against their team and gain back points.


Very little preparation was done prior to the start of the competition. We considered candidate languages for our implementation and quickly narrowed it down to Python and C++. We ended up picking C++ based on the following assumptions:

  1.     Most other teams would use Python, giving us a significant speed advantage.

  2.     Our performance lead would cushion us from the higher potential for bugs.

Build it

We started the Build it round with a team of four, but two of the team members were busy so we were effectively a team of two for this round. This caused a bit of difficulty to begin with but, was not a huge hindrance.

This year’s specification was for a “secure log” for an art gallery. Correct implementations had to encrypt the log file, and maintain the integrity of the log by disallowing invalid actions (As an example, a person could not enter the same room twice). We broke the program up into approximately 5 major components and implemented each piece.

The log was required to have two separate interfaces, one for reading another for writing. We attempted to be as object oriented as possible and not reuse code anywhere unless absolutely necessary. We split the code into a simple state machine, a log file reader, a log writer, a parsing routine and the cryptography. This allowed us to work independently but still work together towards a coherent whole. Each task came with its own inherent difficulties and was a bit of a challenge to get 100% correct.

For crypto we used OpenSSL and encrypted all log outputs as well as using an HMAC on the file as a whole to ensure no tampering was possible. Ultimately our design decisions produced extremely quick and nimble code.

Due to ongoing issues with the scoring servers, only 3 teams were able to submit valid submissions. The Build it round was extended to next Tuesday. We spent the extra time reviewing our code and throwing tests at it. The amount of issues found after our weekend coding marathon was enormous including many vanilla security issues overlooked due to the brevity of the competition. Thankfully we had the extra time to shore up the code and put together a pretty formidable defense. We also found a few issues with Valgrind and fixed them up ensuring our memory handling was relatively sound. At the end of the round, we were an impressive second place with a score of 1715 only 10 points behind first place! Our results from the build it round can be seen here:

Break it

The break it round commenced only two short days after the build it round but fortunately we were able to have all four of our team members participate. A major strategy for our team was to using the testing framework provided and write custom tests to attempt to fuzz out problems. We were able to find a few vulnerabilities in some compiled language submissions and even a few logic flaws in the interpreted languages.

Overall our team spent more time auditing the code for vulnerabilities and logic flaws but spent far less time analyzing the spec and looking for deviations. This ultimately showed in our break it performance, which unfortunately was not quite as good as we had hoped. We were able to find some vulnerabilities and solid bugs but those took much more time than originally anticipated.

Our code also seemingly did not stand up well against the break it round. We had a lot of bug submissions and became very curious as to what was the root cause of our problems.

Fix it

During this round we were tasked with reviewing the bug submissions that other teams had made against us, and finding ones with the same root cause. Before this round we were very low on the scoreboard due to numerous bug submissions. Fortunately for us many of these submissions were identical to each other and a few were blatantly wrong.

There were also a few bugs that were due to confusion with the contest specification and the judges were kind enough to award us those points as well. This round coincided with CSAW CTF so the only member of our team that was able to participate in this round was Kiwi. Despite this handicap we were still able to get a large amount of our points back and moved quickly up the scoreboard.

Here is a link to the final scoreboard:


Ultimately we ended up in third place overall only a few points behind first and second! We are extremely happy with our placement despite using an inherently dangerous language. One of our major issues came from simply not reading the spec as closely as needed causing many of the bugs to simply be from human error.

Overall the contest had a few kinks in the infrastructure and the testing frameworks but the amount of work and dedication shown by the judges was truly amazing. We all enjoyed this contest a ton while also learning a lot about C++ programming as well as exploring some lesser seen languages. We wanted to give a big thanks to all of the organizers and staff that made this competition possible and a special shout out to @awruef and @jp_rider for fielding all of our questions quickly and aptly. Feel free to check out our submission on our Github page and leave comments below!


Looks like we actually came in fourth after some last minute score updates. :(