Happy to answer questions.
One obvious question we haven't answered: how long will it be up for? Answer: a'unno. Until it gets boring? Or super expensive? We're in no rush to shut it down. I've never understood why awesome CTF events are so eager to shut down.
Here's what it looks like:
http://twitter.com/tqbf/status/423992147155509248/photo/1
We're on Freenode #uctf if you want to bug us live.
In case you're interested: this is a very small Rails app talking to an emulator we wrote in Golang that exports an HTTP/JSON interface.
> I've never understood why awesome CTF events are so eager to shut down.
We actually were planning to leave the first Stripe CTF up indefinitely. We'd mostly just built it as a side project, and hadn't really expected anyone to take notice. But we were swarmed by thousands of users, and suddenly keeping everything running was a full-time job — Andy wrote a script to alert us to forkbombs, and every hour or two we'd have to go in and clear out the forkbombs from a machine. The runner for level5 would get wedged due to an exploit that hung it, and would require kicking. One of the machines would be overloaded with level6 password bruteforcers, and we'd have to spin up another or kill off runaway ones.
For the second CTF, we at least knew what we were in for and built a much more resilient architecture. It was successful in that it was much less work to maintain, but there still was a lot of maintenance, ranging from working around an EC2 security groups bug that would blackhole traffic from certain client IP addresses to spinning up more level2 boxes (since everyone was overloading them in their attempts to bruteforce the level8 passworddb).
Anyway, my tl;dr is that running any production system is hard, and we couldn't have kept them running without significant time investment.
On the other hand, we're a security consultancy, so maybe we have lower, more tolerable standards for "up in production" than Stripe does.
Nelson Elhage is a machine; he ripped through 9 levels in under an hour.
I looked through the manual and saw the instruction 'cmp' tests the two parameters for equivalence, but I don't see 'cmp.b' anywhere. I found the TI manual for the instruction set which happens to say something about '.B' being a byte operation, but I'm not sure if that's related.
The tutorial explained that @r13 uses the value in memory for the address in register 13, but '0x2400(r14)' is really confusing.
I was thinking it just meant register 14, but that doesn't seem to be the case because the comparison fails when r14 (which is the value 0x0000 at this point) and @r13 match. I thought it also could mean the literal value '0x2400', but the comparison still seems to fail when it should match, and that doesn't explain the r14 in parenthesis at the end of it.
In any case, thanks for the link!
This is Firefox 25.0~b1+build1-0ubuntu0.12.04.1, on Ubuntu 12.04. I'll try it on something more modern when I get home.
Looking forward to it!
This looks like it will be a lot of fun, though.
Agnes: What appointments?
Dean Pelton: ...Wishful thinking.
Damn. There goes my weekend.
This is AWESOME, thank you for putting it together. This should be mandatory training for developers in languages with no bounds checking. It's downright scary how easy some of these exploits can be. Yes, I know x86 makes things more complicated, but I had no idea the basic concepts could be so simple after reading disclosures about buffer overflows, stack smashing, and other spoilery stuff I won't mention here. Working on Algiers right now.
Minor bugs: I like to hit "enter" in the debugger to keep single stepping, but every now and then the focus disappears from the input window. Typing "s" works because it seems to jump back to the window, but typing "enter" does nothing.
Several levels produce garbled text from puts() -- doesn't affect the playability, just looks funny. Or maybe you fixed that already, I'm not able to reproduce it now.
It would be nice to be able to copy/paste from the memory dump to the disassembler without having to trim the other columns off first.
And the cherry on top: remember my "hide box headers" setting. Thanks!
In most cases, it won't let me see the scores for levels that I haven't beaten yet. Presumably this is because seeing the input size and min cpu cycles would be a strong hint about how to solve the level.
However, when viewing a particular user's profile (e.x. https://microcorruption.com/profile/294), it shows their completion stats for the level you are currently on, despite having not beaten it yet. The levels after it are still obscured, though.
I've always been meaning to try out a few public problem sets of this sort that a couple university security courses publish. Theirs are often based on a VM image with various binaries inside them that you are supposed to exploit. While those would probably have the advantage of being slightly more relevant to my everyday work (since they're running a Linux OS/environment more like the one I regularly use and program for), this contest makes it much easier to get over the hump of setting everything up, and of course the points/competition aspect is highly motivating.
Nicely done. :)
Nowadays I see these and I have to practically tie myself to the ship's mast to not drop everything I'm doing and sink days into it. I couldn't resist with Stripe's CTF but had to quit after I got busy. This one's especially hard because I love tinkering/building embedded devices.
I guess the point is please, please keep this running as long as you can so I can have a crack at it when I'm not working day and night =].
Having not really touched assembly that much before, I found the tutorial to be an excellent introduction. I'm now battling with level 4 after thinking I wouldn't even get past the first level.
Great work Matasano & Square!
Suggestion on top of that: It would be really nice to grab the whole 'firmware' and dump it to a local .hex file. If that isn't allowed for obvious reasons/by design: Fair enough.
This is very cool and I think would be "even more awesome" if there were a separate version that provided a tutorial for the skills required for each level.
For us 'tards. :P
Also, I want to compliment you on the interface, my laptop broke yesterday and I'm doing this on a borrowed Acer A500 tablet without any serious problems.
