 Hey, my name is, my name is Pub, Dr. Gonzo's my handle. I'm actually here with Hacker Joe and we're going to talk about basically how we ran Capture the Flag for the past four years. Is anyone not familiar with Capture the Flag? All right, we'll find out a little bit about, put your hand down. Yeah, so we'll talk a little bit about sort of the intro of how it works and kind of go through some of the neat things that we did with the game and some of the ways that we basically just drove people completely bonkers trying to reverse engineer things and hack into code that they've never seen before. So just to give kind of an intro to the rest of the folks, because we are a very small part of a group. We have Invisigoth, Metro, Verbal, Bob, who's around here somewhere, the other guys aren't here. Of course Hacker Joe and myself, Blackout and RaceRacks. And we've had some folks, you know, we've been doing this for four years. So, you know, some of the folks that were on years one and two have left and we've pulled some new folks in since then. But yeah, that's basically the whole story. And I have to thank all of the gophers that have ever helped us run it. I don't think it would ever be possible because you get, you know, a group of like say 10 geeks together and you realize that they'll sit down and start hacking code. Nobody's like eating for like 24 hours. And, you know, everyone's just kind of like, you know, ugly and dirty and smelly and you really need people to kind of help out because otherwise you just sort of spiral off the deep end. So none of this would have ever been possible without them to sort of keep us fed and red bulled up and all that kind of good stuff. So I'm going to actually turn it over to Hacker Joe to kind of go through the background of Capture the Flag and how the game sort of evolved over the past four years that we've been doing it. And then I'll take back over and talk about some of the lessons learned and some of the crazy shit that ended up happening. And then at the end we'll talk through some of the particular challenges that we had that were always, some of them were a little fun, some of them were just crazy hard. And hopefully you'll enjoy it. Annoying noises with the mic. Okay, so for the past four years, Conchotto ran CTF for the three years before that is the ghetto hackers. Talk a little bit about the background and the evolving of the game. Pretty much if you look at the background, a brief history of how it works, it started as a game. You've probably heard Capture the Flag and lots of other things at Halo Capture the Flag tournaments. Kids play Capture the Flag. You put one kid on top of a hill, king of the hill contests. Anyways, the deal is the guy with the points wins, right? The Capture the Flag at DEF CON has been a head-to-head team-based hacking contest. An all-out little elite skills testing game, running for three days. It's in the big room down there. Those of you who've walked by in years past probably know it as, don't know what CTF was, knew it as the game, the big room with all the cool videos running. Thanks to Bob's. But the idea is to be a real-time test of offensive and defensive skills today. Where it evolved to over the years is a lot of application security versus the traditional host-based security. But the idea is each team has a server. They're going to set up. You have to attack, you have to defend, and you have to have the most points to win. Game setup in the past is kind of looked like this. You've got the eight teams running around the room. Very early picture. It's not a disaster, which it'll look like on Sunday. There's a star topology for the network. Our table's in the middle. The team's around the edge. We cable everybody in, and all the teams play head-to-head. If you look back at the history of where it went, if you look at the early days of DEF CON coming up, we call them the stone ages. All the way up through years, DEF CON 4 through DEF CON 9, the dark ages of chaos, you had various different games run mostly by the goons. You had games that were run just in complete chaos, just a whole bunch of people got together and decided to say, hey, you're the red team, you're the blue team, you guys defend, we'll hack. You had a game that evolved over the years and started getting organization. You had groups that would show up to be admins. They would bring servers to defend and defend. You would have groups that would show up and be hackers. But you still had a very chaotic game with scoring that at one point got as bad as you raised your hand if you thought you had root on a box and somebody came and verified it. It was kind of silly at some point, right? You had people sleeping in boxes in the room to prove they could hack all the servers where everybody went to bed. You had this very chaotic. And then it started moving. It's kind of what we called the golden age of ghetto. The ghetto hackers took over at DEF CON 10. And they said, we're going to build a game that has a structured organization to it and we're going to qualify teams to come play. So the first time that the game wasn't walk into DEF CON, play capture the flag. So they qualified teams, ran a game with eight teams playing head to head. They named their capture the flag game Root Foo. And some people I think I heard it called Root Wars. But mostly Root Foo was the name you saw prevalent there. The last four years, the Concerto Renaissance, the game changed drastically yet again. And it moved from to the same style. We qualified teams to show up and play. We moved a lot more into the application space. Initially, we even moved away from the defense and we'll talk about that. We actually let the defense back into the game as we realized we moved too far away from that. There's a talk immediately after this one by CypherTex who was on Atlas's last place team who's played the last couple of years who's going to go into some more of the history in the game and what it's like playing the game and how you win CTF from his opinion since they've won. So that'll be a different talk. We're going to talk a little bit about different things. So looking at those past four years, like I said, we qualified the teams to show up. How that happened would be somewhere, it was always the end of May, beginning of June, we run an online challenge called qualifications or quals for short. Typically we have about 200 teams now playing in the quals. I think DD Tech who's running it this year announced they had right about the same. They had a little over 200 teams that signed up, played online in the quals. The popularity of CTF growing has been interesting to watch and it's been even comical stories like year two while we ran the quals. We had it running at John's Company. We had a hosted VM at John's Company, right? Quals are running, all of a sudden our quals server disappears. Call back up John's Company like, yeah, we shut you guys off for hacking. Yeah, really, seriously. They turned us back on about an hour later. They shut us off again. We were starving the resources on the whole server. It took about four hours. We actually relocated it, ran it off a server in my basement in Atlanta because at the time I worked for a cable company and had an uncapped cable modem. So we had mad bandwidth. So quals ran that year in my basement. It was kind of fun. But you've got to be prepared for this, right? You get popular and you have 200 teams trying to brute force their way through mad binaries you've put on a server. It can get overwhelming. In the quals, one of the things that we kept was we've always invited the champion back. Very rarely has the champion been able to repeat their victory twice in a row but we've always invited them to come back. So whoever wins, we've always kept the same as ghetto has it. Whoever won last year gets an automatic seat at the table for the next year. DD Tech kept that privilege this year and invited the winners back automatically and they've moved it up to ten teams this year. So they qualified nine plus brought back the last year's champion. So some evolving of the game. So how's the game changed? As I said, now we have eight teams. So if you remember just before ghetto took over, if anybody was at the Alexis Park, you can remember just walking into a big room and seeing long tables of hundreds of people just trying to sit around tables and play with no idea who was doing what. You saw now that it's organized by team. Not only that, but they actually color coded. You see the color coded banners on the table. The scoreboards color coded. You can track what's going on. The architecture is built with, you say, a specialized network architecture. We'll have some slides on that a little. Bejesus turns out it gets hard to run a hostile network in a hacking competition. Imagine that somebody likes to hack your network. Typically, we've given each team 20 to 25 custom services. This is the big change Kinshoto made. We didn't stick stock services on. You weren't defending your mail server, a web server, Talnet, SSH. You were defending 20 to 25 custom applications written by Kinshoto. All had unique exploitable conditions in them. Sometimes they had other unique exploitable conditions that Kinshoto didn't think would be in those. It's all good. You get points for steals, overrides, breakthroughs, and an SLA. I'll give you guys a hint on how we ran that through there. The scores are steals. All the services have in them some sort of a key. You have to find that key. If you can find the key in the service, which means you've gotten read access, someplace that wasn't necessarily exposed in that app, or maybe it was exposed and it just had the key out. Some of them are very easy. You could take that key and we had a key submission system, and you could submit your key and score points for a steal. One point for each key. We replaced the keys randomly about every five to ten minutes. We'll talk about that a little more. There was also a second level. The next harder level were overrides. If you could replace the key, when we came back and looked for a key, or we were looking for the key to have changed through the operating system, if the key is overwritten, you get the overwrite points. If you're the blue team, and you've stuck your key on the green team server, we check the green server and pull back blue's token. Blue gets points for an overwrite. Breakthroughs. Here's the challenge. You're on a wide open network. It's like the real world. You write a vulnerability and put it out there. Everybody knows it. You're unique. This is gone as soon as you expose it. You can't pull it back off the wire. So the first team to successfully land an overwrite gets breakthrough points to reward them for having a working exploit that actually landed a payload. The second team and the third team are also given points, maybe because they also solved it on their own, or maybe they were the first one to recognize it on the wire and replay it. Regardless, you're the second one. You get half the points. You're the third one. You get a quarter of the points. Breakthrough points are done for that service. The services are on difficulty from easy, hard, and ridiculously hard, we called Consciotto. The overall score actually was multiplied by an SLA. This was a big change in the game in the state. You had to keep your services up and running. We checked your services. As we pull your services if they're not working, we're going to take points away. We're going to deduct your SLA. We're going to take all the points you scored during the game, and we're going to multiply it by your SLA at the end. So if you shut all your services off, you can root the boxes all damn day, and you're going to get zero points. So everybody has to keep their targets up. That way everybody gets to hack all weekend. So that's the way it broke down. You ready? All right. I headed back to Pub to go over some of the lessons we learned in kind of evolution of the game theory. There's actually two other scoring things that we forgot to mention, which was penalties. So if people were being idiots, we would penalize them. It would also cost people some points. And then there was also the standing rule that we had since the first year we did it, which is you can attack our game infrastructure, and if you own it, then we'll give you points. But if we find you before you own it, penalized. So, yeah, but thankfully, I don't think we actually got owned too badly throughout the years, which is kind of a good thing. Okay, so let's talk about some lessons learned. As H.J. mentioned, running a game for hackers is kind of hard because people can see... I mean, anything that they can see, they're basically going to attack. I mean, that's sort of the environment you're putting it into. You're basically throwing a bunch of bloody meat in the water and waiting for the sharks. So you have to basically allow people to explore everything that's on the network, attack anything that they find, but you have to keep your game infrastructure, the backbone, so to speak, kind of protected because otherwise pretty much the whole thing goes to shit. You don't really have a game anymore. So that has a huge amount of implications for how you actually design things. And effectively what that ends up coming down to you is that our network topology just got strange and I'll give you an idea of how strange it got. So let's say you're a team competing in the game. So H.J. mentioned that we have kind of a star topology. This is what it would look like to you. So the idea being that you have sort of the eight teams that have their servers that are across the bottom, the eight teams themselves actually cable in on the little clouds that you see in the middle, and that they're all connected basically to a router. So a team effectively kind of sits between their server and the game network and they just plug them into a switch together and then their server is on the game network. Hopefully pretty straightforward, yeah? Well, the actual design of the network itself was a little bit more hardcore than that. It actually looked like this. And just to give you an idea, I guess I can talk through it a little bit, though we'll probably save a lot of the questions about it for Q&A if you really want to know, because it's a little bit bonkers. But the idea is that each team actually had a server that was running in a FreeBSD jail. The FreeBSD jail was running on a FreeBSD instance that was running in VMware. There were four VMware images running on each of our physical hosts. And then basically that allowed us to actually have a back channel into each server, so we could actually log into the host FreeBSDOS and poke at things that were happening in the jail without really worrying about it. It also gave us the extra sort of built-in suspenders feel that you would have to be able to actually break out of your jail and then break out of VMware in order to actually attack our game infrastructure, which made us feel a little bit better. Nobody managed to pull it off, at least to our knowledge, unless they pulled it off really, really well. So the rest of the stuff that you see on the side are actually parts of the infrastructure. So we talked about running service polls that's got to come from somewhere, right? So we have a polling server. Each team actually has a lot of database-driven applications that they're defending as well. So we have a database that sits on the back end. I'll talk a little bit about that in a second. And we also, of course, have the scoring server that keeps the tallies and everything else. And then across the top, you have things that run the game itself. So we have the scoreboard that actually projects up on the wall that's tied directly into the game network. And then the firewall itself. And there's actually another box on here that I'll talk about in a second that's affectionately known as our... What did we call it again? The packet fucking sprayer? Yeah, we'll talk about that in a second. Okay, so why so complicated? I already talked about a few of these implications, but the idea was that when you're scoring overwrites, how do you actually detect if someone's running a... you know, they're just running a service on a server that they control, how do you detect when someone overwrites it? As it turns out, the way that the ghetto did it was actually pretty simple. They would actually just come in with a polling server and grab the key, which caused kind of crazy conditions where people would own a service and then write a tight loop that would just keep overwriting their key so that whenever that polling server came by, their key would be the one there. They would have teams owning the same service. All of them overwriting thrashed machines, thrashed drives, kind of a mess. So the way we did it instead was to actually have a kernel module that would... a kernel module that would basically monitor the files themselves. And so as soon as you got overwritten, basically you could overwrite a file and then cap the file and it would look like nothing happened, but the kernel module would detect that you actually overwrote it and score your points automatically. We had also database triggers set up. So as soon as you would actually overwrite a field and a database on a particular table, it would automatically detect that you did that and score your points as well. So the scoring itself was very much streamlined so that you didn't really have as many sort of race conditions and people that actually owned services would get points for them as soon as they did, which was good. Of course, the rest of the complication was due to the fact that we wanted to keep most of the things that were actually game infrastructure outside of what the teams could actually get to. And another kind of requirement that we wanted to uphold was making it so that you didn't actually know who was attacking you. So effectively, if you were sitting on a team network, it looked like every connection, at least for the first couple years, it looked like every connection was just coming from your gateway address. So you were sort of sitting on the other side of a NAT, so to speak, so all the rest of the seven teams were NATed to your network, which added a lot more complication as well, but it was cool because that way you wouldn't really know. And of course, you don't want people to be able to pose to detecting other teams' exploits, because otherwise they would just write some firewall rules or put something in line that would just block all the other teams' traffic and just allow the polling traffic to come through, so it would look like they were up, but nobody would actually be able to attack them. So that's an important part as well. So server access, we actually always ran all the servers on our hardware, on our systems, because at least for the first couple years, we didn't want to have any inline defenses. We didn't want people to put up packet filters and things of that nature that would filter out shellcode and things like that, or we didn't want people to do server replacements. We wanted them to actually play the game that we set up for them to play and make sure that everyone was playing on equal footing. And in addition to that, we wanted to have kind of a consistent game state, because of the layers of JL inside of VMware and so forth, we were able to just do things like take VM snapshots and so forth so that if someone came up and accidentally hosed their own VM we could just go and revert them to a previous VM or snapshot and that kind of stuff. So that worked out pretty well, all in all. The problem was that you still have to, if you're doing that and you're keeping all the servers yourself, you still have to give teams a packet dump of the traffic coming to and from their server, because otherwise it's really difficult to see what the hell is going on and to understand what any other team is doing. Because they're running in free BSD jails, you can't give them access directly to the interface because it just doesn't work like that. So we had to kind of come up with a way for every team their packets. Hence, now I'm about to tell you about the packet fucking sprayer. So we had this problem, the first year we were doing this we thought, oh, we had it all drawn up on a board, like this is perfect, this network architecture is totally going to work, we're done. All we got to do is go in, bang out some PF rules on a box that has like 10 interfaces on it, we'll just put a trunk line that has eight VLANs running over the trunk and we'll just break it out. We'll just make it like an eight port span for each VLAN, so each VLAN as it turns out, we actually have no idea how to do that. And so the first year I sat down, I think it was the H&M we sat down and we were kind of scratching our heads, writing some PF rules, we had dupe twos going everywhere and all kinds of madness. And the packets just weren't leaving the box and we just couldn't figure out why. You know, we had this coming in, we had the VLAN separated properly, all the rules were there, why weren't the packets going out. And so hence the outstanding challenge which stands to this day. If someone can tell me how to do this, I'll buy you a beer, I'll buy you a bottle of vodka. Any vodka you'd like. Because really as it turns out once you have this problem, you can't get the packets out of the box. Why? Anyone know why? Arp. Well behaving nicks don't actually send packets out on interfaces that don't have ARP entries for the IP that you're sending it to. What's that? Well, I mean if you do it on a Cisco, I'm not going to be impressed. So, yes, let's say. Yeah, the idea is that effectively the teams were walking, so we sat down at around 10, 11 o'clock on the first year we were doing this to try to figure this out. We're going, it's like 3 in the morning we're like Jesus, we're supposed to start this thing at 10. Still going, 7 in the morning. Sandwiches and Red Bulls come in. They're still not working. Eventually the answer was to open up the FreeBSD kernel code go into the ARP Resolver which is like this big long routine of how to actually resolve ARP addresses properly. Go past the local variable DEX DEST adder sub 0 equals 0xFF semicolon. DEST adder sub 1 equals 0xFF semicolon etc. through DEST adder sub 5 until you're basically hard coding in broadcast ARP entry for every packet that's going to go through the machine. Return. Make World. As the teams were walking in with equipment Make World, thing worked. Yeah, and then H.J. takes the box home so that he can actually get, so that's where we're doing all of our packet dumps, like just TCP dumps so that we would have traffic logs. Takes it home and ignorantly plugs it into his network and everything goes nuts, because any time a packet hits that box, guess what happens? 8 more come out. Yeah. It's a little ridiculous. So anyway, so that was the whole idea with that. So anyway, we eventually allowed inline servers in the last year that we did this, actually maybe even in the last two years. That was kind of good for us, because we didn't have to hack a free BSD kernel. Okay. The running of service polls. The service polls themselves, we actually wanted to make it so that they sort of look like normal traffic, because if you can tell what a service poll looks like, you can pretty much game the game. So we had lots of randomization, both in the timing that the service poll would run as well as the actual messages and the payloads that the service poll would deliver. And we didn't actually run service exploits from our service polls. We just made it look like someone was coming along and just poking at the service to see what it did. And I'll talk a little bit about some example services that we had, and that's kind of where we're going in this talk eventually. So, yeah, freaking TTLs. So the other thing that's kind of complicated, you'll remember, well, you may not remember, but the network diagram that I put up there a second ago, the polling server was away from where the rest of the team servers were, and away from where the rest of the networks were. As it turns out, the polling server is actually one hop closer. So if you don't actually go to all your infrastructure and adjust the TTLs via like sys controls, then you can really easily tell where the polling server is coming from by just looking at the TTLs on the packets. Because the TTL is going to be one higher for anything coming from the polling server. Which is kind of a neat one. I think people actually found that out during the ghetto years. Like when ghetto was running the game. The last year people had TTL firewalls up, which was kind of neat. The first couple years, it didn't really matter because we didn't allow people to actually get in line. The first year we allowed people to get in line, we botched up the TTLs and then fixed them like pretty much after the game started. And then the last year we finally got it right. Okay, let's see. Oh yeah, service status. Okay, so with service status, the way the ghetto always ran the game was that they would not tell you what the service status was. They would just give you a vague idea about how many of your services were up. It was kind of a rough percentage. So you'd be able to say, oh, we got about like 80% there. And then when we were running the game, we tried to kind of carry on that same idea at least the first couple years. And as it turns out, all that really causes is every team to have a gopher that comes up and asks what services are up. Like, oh, is the ABC service up? Is the BAR service up? Okay, sure. So that got really annoying. So we ended up just kind of giving teams the exact info that we had on the latest service polls. So we did that in the last two years. Turned out that works out really well. So that way teams can kind of self-service less running around and a little bit more of concentrating on actually playing the game, reverse engineering and hacking into the challenges just a couple of technology highlights from the years we've done this. We have well over a million lines of code that's checked into our repository for actually running this game, which is kind of retarded if you think about it. And then we actually have a huge amount of reusable infrastructure. So the standard progression, I kind of joke about this because it happened with ghetto too, at least for the first, they ran it for three years. We ran it for four, but for the first year, your team is so gung-ho to go and run CTF that you just knock it out of the park. You're working together, everything is streamlined. Year two, you're like, oh, it was easy. We got this down disaster. So year two, it wasn't a complete disaster, but there was definitely a lot of headaches. We spent a lot of time running around and a lot of time wondering what the hell we did wrong. Year three, you have to do it because no one wants to go out like a chump, right? So you got to do year three properly. And then that's when we really put a lot of time into making game infrastructure completely rock solid. And then so for year four, we basically picked the same pieces of infrastructure that we had. We're able to use them and just effectively had to recode a lot of challenges and things like that and just invent some new challenges. But the infrastructure itself was stable, which was kind of cool. The other thing to consider is that we actually build two games every year because running Qualls is basically a whole separate adventure. The way we've set up Qualls, I don't know if you guys have ever played in it or seen it, it's sort of set up like a Jeopardy board. So you have, I think, what? Five categories times five questions each. So there are about 25 challenges. They get harder, much like in Jeopardy, and they cover a few different types of categories and things like that. But that's basically completely separate. All that does is figure out who gets to actually show up here. And then when we actually run the game here, it's a completely new set of challenges, a completely different kind of game. Oh, yeah. The other thing that was built along the way was that we really were doing a lot of our back-end infrastructure, most of it's almost entirely in Python. And we just were unsatisfied with other Python-remoting libraries that were out there, so Invisigoth basically built us up, which is kind of neat, and it works incredibly well. And we actually had custom harnesses that we wrote, because when you're writing challenges for so long, you don't really want to write the same routine to drop priives or to do whatever rudimentary functions that you need in just writing a service to do obfuscation, which we'll talk about in a second. So we had a bunch of custom harnesses that we wrote to make writing services and writing challenges pretty easy, and it was pretty funny because a lot of the guys, I didn't participate, but a lot of the guys around during quals when GD Tech was running, the guys that are doing it this year, and we just did a little bit of poking around in some of the binaries, and they were using our service harness, which is kind of neat. I don't know how the hell they got it, but yeah. So, yeah. Okay, so let's talk about some of the actual challenges that were in the game. So there's a... I picked, you know, I talked to some of the guys and we kind of picked some of the ones that we thought were some of the more fun ones, to have to actually beat. And so hopefully you'll enjoy what we talk about here. So some of the general things that we did just to kind of frustrate people and to make it more challenging was that we always strip symbols. There's no point in having symbols in it because if you can reverse engineer, you don't need no distinct symbols. And then we had a bunch of macros that we used to make things just kind of screwy when you would open it up in a disassembler. So one of the favorite ones was that we would have jumps into the middle of what, you know, put it up and I didn't look at it, you would see a couple of instructions and eventually you get the one that's like, what does that instruction do? And you scratch your head for a while until you realize it doesn't do anything. It's not actually an instruction. Because it actually is... You jump into the code at a weird offset, so a couple byte offset, so that you're actually executing sort of not in the same way that a disassembler would. So you just have... You have to kind of reset things in order to reverse engineer it properly, which is kind of neat. So it kind of messes up disassemblers. In a lot of the challenges that we had, there were some common shellcode characters, so you would have to actually write your own shellcode. You can't just go pull it out of one's paper and try to use it. It's not going to work. So those are some of the common characters, so just FFCBs, that kind of thing. So yeah, and then let's see. Let's talk about some of the specific challenges. We'll start with one of the favorite ones. At least it's one of our favorite ones. You may think this is a little stupid, but this is what the challenge was, and let's see if the audio works. So the challenge was basically you got to listen to the BBS that's actually being discussed in it. Yeah, as it turns out, we couldn't actually find a damn modem. So we all sat around Metro's living room with his girlfriend looking at us like we had seven heads and we just lost our minds entirely. And Bob was sitting there with his laptop trying to record it because we didn't have a microphone either. So we were sitting there like, all right, one, two, three. Yeah, we had to rehearse making modem sounds like four times. It was absolutely retarded. Yeah, big fun. So again, that one's not so difficult, right? DTMF, then do some Googling, you'll figure it out. Okay, next one. This one was called Goes to Eleven, which was basically a very simple program. It just was a network listener, opened up a socket. It allowed you to send some data, and it would basically just cast that data to avoid star and then invoke it like it was a function. Except you only got 10 bytes to work with, which is actually pretty challenging. So you have to figure out 10 bytes of basically opcode that will actually basically make a remote exploit. So a bunch of people solved it, but we ended up getting it down to eight bytes. And I think one of the other teams that was playing actually got that as well, but that's about as small as it can get as near as we can tell. So that was another fun one. So that was, again, sort of basic, pretty simple. Okay, the TNICS service. This one was one where it would prompt you for a password, which was basically just straightforward brute-forcing, except it would actually drop your connection as soon as you put the wrong character in. So if you just grabbed a password brooder and started running it against it, it was going to take a long time. So you would actually have to write and do it by hand, which pretty much everyone just wrote a custom brooder. So that was another one. It was, again, pretty straightforward. So those are the easy ones that I covered so far. Let's talk about one that nobody figured out. We called it Math Is Hard. I don't know if you noticed, but we name all of our services after just whatever we happen to be thinking of at the time. So the Math Is Hard service actually did waveform analysis. So it did an FFT of whatever the input file was. And if it received the correct input for whatever the correct input was, it would actually give up the key and it would just hand it to you. Which doesn't seem like it would be that hard. Perhaps you could reverse engineer all the math that goes into that. Except we went in and changed it so that there was no more than just a couple of instructions before there was a jump. So if you actually try to open it up in Ida, it just explodes. It says that there's just too many branches for it to actually do a control flow graph for you. Which makes it really hard because then you have to sit there and reverse engineer a huge amount of mathematical operations that are basically like two instructions jump. Two instructions jump. What? It becomes a bit of a mess. And the right answer was the theme to... If you actually fed it that file, it would work. Yeah, which was kind of a crazy one. So just to give you an idea of what it sort of looked like, I won't make you stare at this for too long because it might scare people running out of the room. And you probably can't read it either. So that works out. So the idea was that... Well, effectively what you see at the top were just a couple of instructions that... And that's what it looks like if you just open it up into Ida. But once you actually undo some of the jumping around madness, it's actually very, very simple. You just have a move, a comp, and a jump. And then the rest of the stuff that's after it just is totally meaningless. It doesn't really do much of anything because it's an execute. So that was a simple... Well, not a simple one. That was actually a very hard one. I don't think anyone actually busted that one, do they? No? No? So yeah. Okay. Let's talk about the next one. Morse. So we had input. So it just would read whatever input you handed it in ASCII or whatever. And there was no overflow in that part of it. But then it converted it into Morse code, into ASCII Morse code at that, dots, dashes, spaces. And then that was where the stack overflow occurred. Once it was converted to Morse. So you had to actually write your exploit using those three bytes. You had to write a Morse code payload, which is pretty awesome actually. And people did break this one. I think a number of people did. Yeah, which is pretty cool. Kind of a fun one that we threw in there, but yeah. So hopefully you're getting a feel for some of the challenges you made. We didn't just try to find an old bind exploit and throw it on the box. We tried to make some inventive stuff that would cause people a little bit of head scratching, I guess. I've lost a bleed as well, yes. Okay, let's talk about the next one. Neuromancer. This program, basically when you looked at it, if you opened it up into IDA, it just looked like one giant knob sled. That's it. It was just a whole bunch of knobs. Not that interesting. Except you could pass it precisely one byte of input. And then depending on that byte of input that you passed it, it would actually go to some random place that was in the data defined in the program. So something in the data segment. And it wasn't entirely random. There was some calculation to it. And then it would actually XOR the entire knob sled with whatever was found in that data segment or at that offset. And then it would jump to that spot after it XORed the knob sled and then execute it from there. And one such byte actually led to a exploitable condition. So you have to find the right byte. And then you had to do it. And then you had to figure out where the exploit was in the code after it's XORed with the knob sled. Then you had to go back and write the exploit for it. Pretty neat. Yeah. Pretty neat. So I have... Shocking. This is what it looks like when you open it up in a disassembler. Push, move, knob. And then you can see the graph overview is very insightful. Yeah. And that's what the data that was defined in the program looked like. Which if you tried to look at this data directly, it didn't really mean anything because it's all XORed with knobs. So you would have to actually kind of figure out what the hell was going on before you would even be able to decode what was in here. I mean, just imagine it from a reverse perspective, right? You don't know what the right byte offset is. We just picked one and put the right code in the right place and the rest was just kind of other random garbage. But if you didn't know that, you would have to effectively go through and run a knob's XOR against this entire big chunk of data and then inside there figure out what bytes led to what offsets into that big chunk of data. And then from there figure out which ones were actually going to execute and how it was going to execute. So you effectively had to reverse this giant chunk and then you had to figure out which one you actually wanted to use with the exploitable condition. Which is a lot of work. It's a lot easier to write these, I guess, than to exploit them. But just to be fair, and just so I've said it, we've tested every single one of these exploits that we put in there to make sure that they're actually exploitable. Well, maybe not every single one, but I'm pretty sure every single one. I think every single one. Yeah, every single one. I'll stand by my story. Okay. Then we get to Minange Tois. And this one was just such a pain in the ass. I think only one person actually figured this one out. There's three processes that would all fire up and they would attach as debuggers to each other. Which no kernel is going to let you do that and no machine is going to let you do that. So we have to patch the kernel a little bit to allow a debugging loop. And then we did that, which was fine. So all these things are now attached. You've got three services that are all hooked up to each other as debuggers. So the actual code that was inside each of these it was all encrypted. So all you had was a bit of a stub program that would fire up and do the attaching and all that stuff. And all the rest of the tech segment, in terms of the code that was defined in it, was all encrypted. So you really couldn't just fire up one of the programs and try to do anything with it because the keys to decrypt it weren't in there. They were in one of the other programs. So the way it ended up sort of working was that one of the programs would fire a signal. The debugger that was attached, one of the three programs that was attached to it, its neighbor, would catch it, then run a decryption on one of its segments of code, execute it, and then sort of re-encrypt it. So you never actually had anything that was sitting around unencrypted. And the tricky thing about it is that statically decompiling it and trying to figure it out just doesn't work. You have to do it in memory because otherwise you don't really have all the context that you need for what signal got fired and what was the message and so forth. Which is pretty cool. So just an idea of what that looks like when you fire it up in a disassembler is that you really just have a few instructions and the rest just kind of looks like garbage because all of that stuff is actually code. Well, it looks like data, but it's actually code after you decrypt it. Yeah, so that was Menage Duant. And yeah, there was one guy that actually got that one. And this one I think got to be my favorite of all of them because this one was just so ridiculous. This was the one that we actually had in year one. It was a daemon that was listening and so if you were just watching network traffic, it effectively looked like the thing that received basically an excerpt from Alice in Wonderland and then the return that it would send was basically the same excerpt with some things capitalized and so forth. So it would just be changed around a little bit. So that's from a network perspective. When you would actually kind of look at the payload itself, the message that was being sent, it was the excerpt from Alice in Wonderland followed by a relatively unusual amount of white space. So as it turns out, the white space actually was the meaningful part of the message. A tab was a one and a space was a zero. And then using that method, you can interpret what all the white space was following the last valid character or the last actual character. Once you actually convert that into binary, then you have to kind of figure out what that is. So now you have to start looking into the daemon itself to try to reverse what the hell's it doing. And what it actually is, is they were opcodes and operands in an instruction set that we just made up. And it was basically the instruction set for a chip set that we just made up. And there were hundreds of operations in there. I mean, this thing was a full-blown VM for anything. I mean, you couldn't really do that many useful things with it. But it was a hell of a thing to have to reverse engineer. I mean, imagine trying to figure out how to actually reverse engineer some opcodes and some machine language that you've never even seen before and you have no reference to it. We just created the thing. And to actually exploit it, you have to write your exploit in the language that we made up. You have to actually write it based on, you know, your shellcode had to be written with the opcodes and the operands and so forth in our made-up language, which is just bonkers. And there was one guy, Chris Eagle, who actually figured this damn thing out. And he rolls in on Sunday morning, wrote you an interpreter for your stupid language. Unbelievable. It was by far one of those moments where you're like, nah, yeah. It's a hell of a thing. A hell of a thing. Cool. Hey, this one is. So that's actually one of the interesting points there. So he said one guy got it, and you heard us on the other one, one guy got it. Just about every team that shows up shows up with one rock star. So one of the things we did when we write these challenges is you write something that looks tasty and fun for one rock star. You know why? Because he's stuck on it for three days going, God! So it makes it fun to put out something tasty and juicy for one rock star to spend his life for the weekend of Defconn focused on, but they feel really good when they solve that one challenge. Meanwhile, five other guys solve 15 other challenges. Yeah, no doubt, no doubt. And yeah, on that note, that's pretty much the end of what we wanted to talk to you about today. I just wanted to thank all the teams that have ever played in Qualls, have played in CTF itself. You guys have definitely shown some amazing skills and really watching the progression of folks that have actually started in the first year that we did this and where they're at now, truly amazing. Like the one guy we had mentioned before, Atlas. The first year we did this, we didn't actually put this in the presentation, but we allowed individual competitors to play. So we had seven teams and then we had one table that we just had set up as the Ronin. And they basically had no server to defend, and therefore their SLA was always at 100%, but there was only one guy. They were just sort of one-man armies. They eventually sort of teamed up with each other, which was quite smart. But there was one guy that played that year, Atlas. And that year he played, he did remarkably well, but his head was spun around by a number of these challenges that he saw. I mean, he was just like, what the hell, how do people figure this out? And he's actually the captain of the team last place that actually won twice in the four years of CTF in the following years, because the kid just went nuts. Every time we had a quals, he would actually take every one of the challenges, download them all. He'd put up a page, Knops or Us, and OPSR.US. You can go to it. They have all the quals challenges for the past couple of years, along with full explanations. He figured them all out even offline after the thing was done, wrote up explanations for how to do it. So if you're interested in actually getting better at this stuff, I couldn't recommend a better place to go and start playing around, because you can download all the binaries and everything right from his site. And it's cool to see people get better at it. I mean, I think it's an important thing. In these days of web hacking, it's important to remember some of the binary madness that goes on behind the scenes. So that's about the end of it. Thanks for your time. I guess we're doing questions or... Yeah, I guess we're doing them in the other room. Is that the...? 105 across the hall. There we go. 105 across the hall. Thank you.