Go easy on us for a bit; this is a fresh deploy in a new environment and it's bound to be janky. The odds of it not completely asploding tonight are pretty low.
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.
> 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.
Also, fun fact: Nelson was our test solver for CTF2. He also ripped through all the levels there in a few hours. But then he got to level8 (PasswordDB, which was source port counting), and was stumped for a few days. He had a lot of hypotheses about the vulnerability, many of which were much cooler than the actual one. Given it had taken him so long, I decided the level was too hard and made it easier by adding some code that would log source ports. (It turned out to still be too hard, so launch day I released a bunch of hints until finally wgrant solved it, at which point I went home and got some sleep.)
Can someone explain what "cmp.b @r13, 0x2400(r14)" does, and/or how I would find out myself?
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.
Bit late, but what does "cmp #0x7669, 0x0(r15)" mean on level two? I assume it's the same syntax for the second part (offset) but is the first part the constant value 7669?
Does it say somewhere that this is targeting an MSP430, or did you just recognize it? I thought it must be something with a real compiler targeting it, but I couldn't figure out what it was...
PSA for people like me who aren't security specialists: "shellcode" (in the survey) does not mean "a shell script", it means this: http://en.wikipedia.org/wiki/Shellcode
I've worked a lot in assembly, but never tried to exploit anything before. This is like crack.
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.
I used to jump at hacking challenges in high school, blowing off homework and in the summers staying up til 5am.
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 =].
During the tutorial, it seems like the memory dump goes blank for me (it loses its scroll bars, and loses its contents) -- http://i.imgur.com/ta9iykd.png
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.
Additionally -- on the first "Yay!", I don't get the nextlevelbutton (which seems to be what it wants me to do next); gray_bg and youwin_outer remain display_none. I have to go manually put them in place in order to proceed on.
Cool! Notably, it appears that it is based on TI MSP430, which is a real CPU with its own instruction set. At first I thought they had invented their own ISA, which would have been crazy.
I would have loved it to be some old ARM ISA to use it as a testcase for Avatar[0]. On the same topic, FIE paper may be an interesting reading for msp430 lovers[1] (but it needs source for symbolic execution, so doesn't directly apply here).
Just so I can be super clear here: none of the code in this challenge has anything whatsoever to do with anything Square ships. We deliberately made things less realistic to make the levels more fun, and easier to ramp up with.
I encourage anyone who's avoiding taking part because they don't know assembly or reverse engineering to at least give the tutorial a try, you might just surprise yourself!
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.
PWNED! I've never been one to shout at my computer, even in multiplayer games, but I've been doing plenty of yelling over here, and a few victory dances too.
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!
Thanks! If you look closely at the requests we're generating, it's pretty easy to see how to get direct access to memory and to the disassembly. Just don't abuse it.
FYI - On level 3, the "okay" button is obscured by the page footer, and can't be clicked on one of my machines. Scolling down doesn't help, the button remains obscured by the page footer which scrolls with the page.
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.
If anyone is worried about participating because they don't understand this domain very well, don't be. The tutorial is very useful, and the interface is generally very nice. Check it out.
This is embarrassing, but... I'm totally stuck on puzzle #2 (Sydney) since the cmp doesn't seem to match up with what's in memory, and I bet that the puzzles won't get any easier from here! Is there a good resource, trove of documentation, or excellent book for those of us who would love to learn how to do this stuff? The tutorial great, but it was definitely pretty basic.
Not sure if anyone is still checking comments or not. I'm completely new to reverse engineering, ASM, etc. Looking at the cmp statements I tried the changing the endienness of the address being compared, but I still am not seeing that address. For example, when looking at 'cmp #0x3866, 0x0(r15)', to me this means add 0 to the value of r15 and look up the value at that address and compare that to the value at memory address 0x3866. So I'm changing the endienness of 0x3866 to 0x6683. Is this the correct thought process? Thanks.
It's been a long time since i've written any asm, but I just did this. You're almost correct; 0x3866 contains 2 pieces of information, 38 and 66. so you should end up with 0x6638
Encountered quite some bugs with FF (Aurora here), most prominently the highlight wasn't updated when I moved a step forward.
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.
I was all excited with myself for passing the first one after the tutorial and then couldn't get past the second...though I've been drinking.
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.
I went through the tutorial. Seems very cool. Disappointed that "password" worked though - I thought it would show me how to read the value my input was compared to instead of just matching the string (and lucky guessing).
Funnily enough, I had to refresh once or twice during the tutorial, and I started realizing that it was checking it against a known number (9).
Your input wasn't really compared against anything but its length. It took me a good minute, but I figured that out before it told me the password. (because of the tutorial)
This is awesome, I'm having a lot of fun reactivating my assembler knowledge.
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.
As someone completely inept in this niche, I'm looking forward to the results. I hope you share them. You'll probably have to dumb them down for us commoners.
Go through the tutorial at least. It's quite a good tutorial in the concepts of simple reversing (I'm just starting to learn a few things in this area)
This would be a great way to crowd-source the cracking of a digital lock ... I hope you're opening the warehouse that contains all the NSA's secrets (every HN story has to have comments that reference the NSA or they'll be thrown into the dead-pool).
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.