Nice article. I got stuck on level3 and perhaps got close to finishing it, but there were a few unforeseen things that came up. I'm glad I did what I could for this CTF, though. This is the first CTF I've done, and pretty much all the languages were new to me. Definitely a great experience!
Stripe-CTF 3 Writeup
31–40 of 74 posts
Re: Stripe-CTF 3 Writeup
#32Great article, I am really eager to see the solutions in github. I guess there won't be many with c++ solutions. I only found the challenge two days before the end. My goal with the challenge was not to get the best solution, but rather use it as an exercise to practice the different languages and finding intuitive solutions. Level 0 as you wrote was really just a two line change. Level 1 was fun, because I tried to…
Mind posting your code for level3? I got that partitioning was the main trick but I am too unfamiliar with scala to reassemble the responses properly.
FWIW, It was possible to pass Level 3 with ~5 lines of code changed - https://gist.github.com/ajtulloch/e05f75aaa6ba3b5b0241#file-... for my solution.
Re: Stripe-CTF 3 Writeup
#33I think this particular bit says it all. To get blazingly fast results...
> I can say with great confidence that we all cheated.
But I disagree with the word used.
Pre-computing the hash-table and embedding that into the final binary to eliminate relatively expensive calculations when it matters? That's not cheating, that's effing brilliant.
Hard-core software engineering, that's what it is. There's also a saying that the only people who play fair are those who don't know how to cheat well enough.
Well done.
(edit: typos)
Re: Stripe-CTF 3 Writeup
#34I really enjoyed the parts of CTF I was able to work on. I didn't have enough time to finish, but I got through the first two levels and the second flag ( gitcoin ) was actually really fun to implement. I got a gitcoin hasher up to 2M hashes/second on a single machine, but even with that I was no where near fast enough to get any coins when competing against the rest of the field.
I limited myself to doing everything using only "C++11". I had to pull in boost_regex since no one has the c++11 regex support, but I am really liking the new standard and looking forwards to what we can get with c++14
Re: Stripe-CTF 3 Writeup
#35Here are my thoughts: I managed to scrape through level 4 so saw them all - this CTF was fun and educational. Level 4 in particular felt like a real education (for me at least), and a great way to learn. Unlike many others I was fond of level 0 because it brought up questions that even beginner programmers should address - how to organise your data so that you can search through it easily, which was in some ways a preparation for the other levels. For the more expert than me it probably felt tedious or inconsequential, but it was quick to solve, and I thought inviting for beginners and open ended.
Lessons learned for me
Distributed consensus was really interesting; I'd never heard of it and enjoyed reading about Paxos and Raft, even if I don't fully understand them yet. Distributed searches can actually be faster than searches in one process - I didn't believe this but as resources were limited on the server it was true in some cases (depends how fast you can make your search, mine wasn't as fast as Henrik's :).
Big scala projects take an aaage to compile - is it normally this bad in real projects? Anyone care to comment? The remote was pretty slow, so that might be why.
Golang needs package versioning! On level 4 there was a versioning bug with differing versions of the go-raft library being fetched locally and on the server which led to problems setting the heartbeat timeout of raft. That was confusing and annoying.
A few notes for the CTF authors
The dramatic variation between resources on remote and locally was a problem in tests - I felt like that needed to be adjusted for as the local test results were meaningless compared to the server. This particularly made level 3 and 4 difficult.
Code examples are great to get you started, but it'd be nice if there was also a clearly specified API for each one which you were required to conform to, to make it easier to use another language, and if the build scripts simply launched one binary at all times - level 3 had two different styles of starting the servers for remote and local for example, that was frustrating.
The varying test cases were sometimes frustrating, and were too varied and randomly chosen. I completely agree with Henrik that you need small tests. Each run should have say 5 tests which can be run individually (for speed), or as a suite. The downloading of tests broke a few times for me and left me stranded and constantly re-downloading new test data/tests seemed a bit pointless. Proper logging output when tests fail is really important - level3 was particularly bad for this as the diffs were useless; I had to edit the test harness to get decent output.
The use of the JVM on level 3 was pretty painful for me - compile times on remote were in the minutes, and I couldn't even get it to compile locally even after installing another JVM, nor on remote without compiling all the sbt stuff - this one was probably my fault, and I just rewrote with golang in the end. Explicit language independence for all the problems would be great.
Unix sockets felt like an unnecessary distraction which caused pain on level 4, it would have been nice if it used IPs, but perhaps for reasons to do with Octopus that wasn't possible, and on a deeper level, being given broken code to fix just felt a bit wrong and distracting - having slow code you have to speed up is one thing, but having code which feels like it has been sabotaged is another.
Don't bother changing the deadline even if people whine - the contest isn't remotely fair anyway or an objective test, so it's better to have a deadline and stick to it.
Oh, and thanks again Stripe, it was a blast.
The original code and some more writups:
Re: Stripe-CTF 3 Writeup
#36Great article, I am really eager to see the solutions in github. I guess there won't be many with c++ solutions. I only found the challenge two days before the end. My goal with the challenge was not to get the best solution, but rather use it as an exercise to practice the different languages and finding intuitive solutions. Level 0 as you wrote was really just a two line change. Level 1 was fun, because I tried to…
I did both all my solutions in C++. I am going to clean them up a little and post them in my github account
github.com/dkhenry
Re: Stripe-CTF 3 Writeup
#37I love his hash table solution to level0!
I would never have spent much time optimizing such a trivial challenge as level0, but after seeing the leaderboards with such ridiculous scores, curiosity got the best of me, and I had to figure out how people were achieving such speedups.
I used a precomputed bloom filter to get 2641 points on level0, because I couldn't think of another way to avoid doing the expensive processing of the dictionary ahead of time. That solution simply read in the filter from a file at run-time. I thought of embedding the data in the source code to avoid the file I/O, but instead moved on to work on some of the later levels.
Re: Stripe-CTF 3 Writeup
#38I read through this and was amazed by the OP's approach to the problems even though I could barely understand 10% of the reading. How do I learn to think and code like this? I honestly have no idea where to begin.
Re: Stripe-CTF 3 Writeup
#39I've blogged my extremely lazy solutions for the first 3 rounds. TL;DR is level0 used a hash table, level1 found an existing utility, level2 used a hash table. Grand total of about 15 lines of new code.
http://www.codesuck.com/2014/01/stripe-ctf-minimalist-soluti...
Re: Stripe-CTF 3 Writeup
#40I got stuck on Level 3, partially because Scala is a little wacky (but I learned to appreciate it!) and partially because their specs were super terrible. They didn't mention it required substring matching or was case-sensitive until I'd been working on it for 2-3 days and then was out of time. Given the bad debug output (the head of a diff which often didn't show anything and didn't include what term the failure was…
I'd pass a test case locally then push and have it fail because it was slower for no apparent reason.
My theory was that the remote instances were really CPU constrained, and so much much slower than your computer, but for whatever reason local test runs were very misleading. The spec for level 3 was annoyingly vague at first, and the test output was really unhelpful as the diff started with lots of original data and was truncated.
Level 4 was interesting, you should have a look - just the links alone are interesting ones, and I liked the raft paper, which was pretty easy to read even for neophytes. I might try to do better at it locally now when I have time free, but again, don't take local scores seriously, I scored in the thousands locally on that, but below 100 on remote. Must. do. better.