 Yes, let's start with, oh, actually, first let's confirm. Yeah, Barbie, switching. We are, I got it. Brilliant, awesome. All right, so let's start out, do some kind of summary. Let me see where my thing is here. Yeah, so while you do that, hello everyone. Welcome to the, this is the middle of the shift four recap, so of DEF CON capture the flag, Yann's going to be talking about it and recapping where we are right now. And so we just wanna share with you the current state of the game. The game is currently running live right now, so please bear with us if we have to quickly run and put out fires and then come back. We're happy to talk, but we gotta, our first and foremost responsibility is making sure that this game runs smooth. Yeah, exactly. So it's, we're trying to balance a lot of things in there right now, juggle a lot of balls. So Adam mentioned, we're halfway through tick four. This is getting close to the end of the game. There's four hours left in the entire shift four. Shift four, sorry. There's four hours left in the entire CTF competition and the teams are super close. So these are the current scores. Let me show you something crazy. AOE right now is ticking upwards about in 15 ticks, if everything continues as is, AOE will overtake PPP for first place. But the scoreboard is going dark, so they'll never know if they make it or if PPP adapts to defend against their exploits. So can you explain what you mean by going dark? Like people won't be able to see the scoreboard? Absolutely, yeah. So every year, traditionally on the last day, on Sunday of the CTF, we have four hours of gameplay and those four hours are completely dark. So the scoreboard is not updated in real time, but the results are only announced at the closing ceremonies. Likewise here, the last four hours are completely dark, but we'll see what happens when it happens. Yeah, you gotta tune into that closing ceremony to find the thrilling conclusion of DEF CON CTF 28. All right, so this is kind of a live or not a live, a more animation-y sort of overview. We're gonna refresh it so we can all watch it and like ooh and ah. So this, from the beginning, we started shift one at, what's happening? 4 a.m. on Friday, right? On Friday at 4 a.m. and very quickly, within about an hour, AOE started hacking service that we created that where players, it was a Blackjack service written and gave life, we talked about it, or we will talk about it this recap. And then services started getting released that teams were able to start scoring on heavily and PPP overtook AOE to get first place, a team called Samurai with that Unicode character name is in third. And for a while, there was this cat and mouse game between PPP and AOE, basically into day two. This game is very much a story of those two teams fighting against each other so far, but not always. So you just saw sometime yesterday, more Bushmoth Whackers, a team from a lot of really awesome hackers from Russia overtook second place, but then AOE, a bunch of awesome hackers from China took that back and gained very steadily on PPP. And for a while, and PPP is a bunch of very good hackers from the U.S. For a while, they were neck and neck. Like you can see, it's a war of attrition here as they solved and patched and exploited and patched and for a little bit of a context, Yon, that number in the lower right-hand corner, the tick number is each tick lasts about six minutes. Exactly. So we're seeing a really sped up version of the team's moving. Absolutely. And so you can see AOE went up into first place for a long time, PPP clawed their way back as there started being movement lower on the scoreboard as well. So T Delivers and HitCon here are fighting as well. And so this was the state of the game as of the beginning of this shift. And now we're gonna look at what's happening this shift. We see PPP building out a lead, very slow but steady while teams lower down, third and fourth place start catching up. And that's basically where we are right now. So PPP in first, AOE in second, then HitCon, which is a team of HitCon and Bolson, which is a collaboration of two very awesome teams from Taiwan. T Delivers, awesome hackers from China, more Bush smokewhackers, awesome hackers from Russia in the top five places right now. But this can change very quickly. If team DevCon CTF consists of a bunch of different services, intentionally and sometimes even unintentionally vulnerable program that the teams have to protect and attack and find optimal and optimal, more and more optimal solutions for. When a team finds a unique solution that no one has defended against, a unique exploit that they can throw at everyone, it can lead to radical massive changes throughout the game. So that is a, this scoreboard could change very, very suddenly. And some of these ticks, you probably saw it, there was one very specific time where Samurai found a solution for them, and he just went and started going up and up. Cool, so let's see, what else should we give as an overview? Let me give a quick overview of where we are in terms of what challenges we have run so far. And then we'll dive into the individual challenge overviews as part of this recap. So these are all of the services of our CTF. All of the services have now been launched. We've retired one, two, three, four, five of them. So far because they've been solved a ton and really closed out by the teams. And then there are still five running right now. Adam, there's a lot of slack notifications, everything going okay? Yep, everything's good, keep going. I'm silencing, I quit slack and then I'm silencing my phone, cool. Okay, so we have 10 challenges, services, five of them still active. We're gonna go through and talk about a lot of the inactive ones because we can talk about them fully without really keeping anything back and then we'll discuss at a very high level some of the still active ones. Before we dive into that, I'll show you one website. It is called archive.oo. So this is archive.oo, this is where we release after we retire challenges, not all of them. It depends on if they're very easy to release because we don't have a lot of bandwidth during the competition to debug issues. Where we release a lot of the challenges. So the challenges that we have so far retired, two of them, two of those five are already here on archive.oo, so you can click in and attempt them from home. You can download the files. You can host them either on your own machine and we provide, excuse me, doctor containers or you log in and you'll spin up a machine for you to attack. Which is a perfect transition into, what can we transition into the RHG service and why it's not on here? Absolutely. One very complicated service that we had yesterday was called the role hacking game. Or we had it the day before yesterday. But it was, we lost it on our second shift which was Friday night, Las Vegas time and it stayed up and survived until Saturday morning, roughly Las Vegas time when the teams finally hacked it into oblivion. I'm gonna pass the torch here over to Ray Ammer who can talk about the challenge in more detail. And we'll say as we're switching over that Janik Rammer is now an expert in making grids in CSS and HTML as you can see here. So if you have any questions about anything to CSS, HTML related, direct it to the excellent Rammer. Exactly. If you want to get just a glimpse of the pain for developing this challenge, try to zoom in or zoom out if you don't remember. I think Chrome is gonna render this with some non-pixel perfect and a width. And so you're gonna see some cells actually flipping over and then when players are supposed to be moving vertically they're gonna boom diagonally. Yeah. That's amazing. If this happens two hours before the game then you start to freak out and regret all your adult decisions. So why this challenge? The idea was to, it's all online. So we really tried to push the boundary on having challenges where spectators can actually spectate something and not just a bunch of nerds pressing keys on their laptops. And the first idea that comes to mind when seeing players fighting with each other is RPG games. So R.A.J. is a stands for all Acre game or for who enjoyed it, Ray Ammer Acre's game. And the idea was to have some kind of RPG kind of game teamed on Acre's. So each team was controlling a player and in this grid basically there is a live website it is public. I don't know if people can read it but there is I guess a link somewhere. Basically if you go with your mouse on one of these items in the grid you're gonna see oh there's a player or oh this is an item. So each player is controlled by one of the 16 teams that were invited to the finals. And as in any RPG game basically you can control this player and you can go around buy items or from other people or get items and try to attack other people and so forth. So the hacking component here was okay the team you can basically get a USB key or a phishing kit and then launch attacks to the other teams. It was very painful to design this in terms of design. First of all we need a central server which complicates a lot of things in terms of testing because if you have 16 players trying to hit the same guy then you have performance issues or debugging issues it's a distributed system. So it's really really bad. Or security at yes. No there was none, absolutely zero security issue. So one other thing was okay great idea let's have this game but where do you put the flags? So the idea here is that the flags are not on the services that teams usually hack but they are in the game itself. So each team was given like a some kind of program to play with that I'm gonna go to this point that that's the part that actually contains vulnerabilities but there were no flags there the flags were leaving as part of the game. So the idea is that each year round so every six minutes the state of the game resets and each player is born with an item and this item is the flag. So each of the 16 guys actually had player one was born with flag number one, player two was born with flag number two and so forth. So the idea is that if you have an object you can inspect it and if you can inspect the flag you can actually read the flag that you can submit to us the organizers but if you don't own an item then you cannot do this. So the idea was to have some kind of a game in the game where you need to hack people in the game to somehow steal their flag in the game as an object and somehow read it. So it was a cool idea because you know if you start stealing a bunch of flags and then somebody else kills you then all your items are dropped on the floor and so this other guy can actually pick everything up and steal all your flags as it would actually happen in an RPG game. So it was a lot of depth in this game where basically there were many actions. You could buy things, you can force a buy from another player. So you could basically buy the flag or again there were a bunch of objects through which you can run tax and somehow this player, the victim if he didn't have enough defenses he would be locked out, his item would be on the floor and you can pick it up the flag and so forth. The second component was there must be some security aspect in terms of bugs. So the idea is that each team was given like a client. This client somehow if you connect to this client there will be an authentication token that you can use to authenticate to the Azure server and control your own player. The idea was that this client was the only way players could access the game server and this client would not tell you which are the comments. So there was a kind of discovery phase at the beginning where you would see dumb things happening in the game because people didn't really figure out what to do. So I've seen people that are trying to fudge the comments and you've seen people dropping the flag on the floor. They would be very stupid why they did it because they were trying to still discover what kind of actions the game was implementing. The other thing was that these clients had bugs. The idea was that as a player I can find bugs in the system and jump on the machine of somebody else and authenticate myself as another player. And if you authenticate yourself as another player you can push this player to do stupid things in the game and still the flag. So there were a couple of interesting things we've seen that I think were very cool. The first one is that there was a player, I think it was EOE, that started basically hijacking all the players in the game and start inspecting the flag. So basically by just authenticating as them they could read their own flags and the flags are the target player and somehow leak it. Then they started to do something interesting. We've seen EOE, they basically had still the flag but every other teams were without the flag. So every team was actually dropping their own flags. What was happening is that this EOE team was first reading the flag from the other players and they were convincing or pushing other players to drop them. So if another player had the same attack it could not easily read this flag. The cool part is that if you knew the moves you can actually go around in the grid and pick up the flag because now it's on the floor and read it. At the beginning people really didn't figure out how to do this and so there were a lot of flags on the floor and nobody there to be except two, three teams. The last thing we've seen was that at a certain point there were bugs that would let other people control your player and teams actually patched it. And it was PPP that actually was one of the first that patched all the bugs. There were four bugs, four intended bugs there. And so this EOE basically started attacking everybody but PPP was still able to keep the flag. And at that point we've seen EOE actually figuring out the game, picking up some objects and attacking PPP in the game itself and stealing the flag in that way. And so of course you could defend there but you need to play the game. You need to, there was software updates or a jammer to stop Wi-Fi attacks and things like this. PPP didn't figure it out that well. And so the cool part was that after it was a security memory corruption kind of thing then there was still a game to explore and hack people there. And yeah, I think I'm gonna write a blog post on, there were many, many design issues that I think- What about the source code? I saw the source code will be public. But yeah, the interesting part for me was more the design. It was quite tricky. But somehow I think we found a good trade off. And so the reason why this isn't in the archive, right is because it needs this central server and you have 16 teams. It's like very much designed for a challenge specifically for DEF CON CTM, right? The Github propositor is gonna have all the components to somehow replicate this. But I think it's interesting to see how it is designed not really all how to solve it. There is a binary with some bugs. The source code is commented with the four bugs I'm aware of. They are not very complicated. The idea was to push people to pass them fast and so that they need to move to play the game. And at least for PPP we actually have seen it where they were defeated in the game component. In some, it was a very bad idea. I mean, it was a crazy amount of work. The most painful part was the web UI stuff. If you check my JavaScript, I think it's kind of clear. I'm not a web guy, but yeah. I don't think it is web people and somehow I respect them. They keep their mind sane. And you probably know how to reach me. Right, if you have questions, but I'm gonna leave the blog post in a couple of days if I'm still an awesome. Sweet, cool. All right, so that's RHG. Let's see what. In the similar gaming vein, we can take it over to. Let me get just a summary of what teams did what. Oh, cool. So you can see, we take, consider a service to be done when any one team hacks it 600 times. And so that's stealing 600 unique flags across all the other teams. And in this case, we call this last blood as opposed to first blood, the first team to pull in the service. Last blood was made by AOE and was shut down the service. At the time, the runner up Cycor had 200 less flags on this service. So it was quite effective here. In terms of defense, you can also see the total amount of flags lost throughout the entire lifespan of the role hacking game. AOE lost nine flags by being hacked on this game. So that's a pretty impressive achievement there. Yanig mentioned that we try to philosophically capture some something that can be visualizable, something that lends itself out to visualization. We also had a bit of this philosophy of since everyone is remote, we created services that people could directly compete with each other. RHG was one such service. We talked about another site yesterday and we'll talk about more later today. For now, we're gonna switch over to another service in the vein of, oh, Basarot, do you have time restrictions or you can talk about yours right now? We can't hear you. While he sorts out his chat issues, oh, it's probably pushed to speak. Yeah, I bet it's your push to speak settings. Anyways, while Basarot sorts out that I'll introduce this next challenge, it is a challenge that captured the core of a lot of modern program analysis in the search for vulnerabilities. Where is it? That's preview for what's to come. Where does it go? Sound, now we can hear you. Awesome. All right, go for it. Yeah, sorry for the background that you can probably hear my kids crying in the background. I'm here in Europe, it's now bedtime for kids, so it's a bit of a mess around here. Davide, if I can interrupt you for one second, we have a breaking game update. Very long time. Last Blood, Service Slute Machine has been a PPP stole over 600 flags for the service and it is now inactive and down for the rest of the game. All right. Hit that jackpot. Last Blood on Slute Machine. Awesome. Oh, never one. Very cool. All right, go ahead. Sorry. Back to you. So I was going to talk about a bit about my challenge. So did you guys already talk about King of the Years? What's the concept in the previous recaps? You want to introduce it? We have it. You should reintroduce it. All right, so my challenge was a King of the Years challenge. So the mechanics are a bit different from what normal challenges are. So traditional challenges are attack defense, which means that you need to break into the other team service and steal the flag. And typically you score points by submitting these flags. So the more flags you steal, the more points you score, at least for attacks, right? And then you need to defend your service and therefore scoring defense points when your service is not attacked. So for King of the Years, the mechanic is a bit different. So the idea here is that instead, we want to reward better solution. So you get more points by submitting better solution, not necessarily by stealing flags, so no flags at all to steal. Okay, so some King of the Years implement this by keeping state. So the best solution is the best solution overall in the game. Sometimes instead is a best solution that worked for that particular tick. So maybe it's a game in which they need to play once against the other and the best solution in that particular tick will get rewarded by getting more points. So that's the mechanic. So it's really to try to push the teams to develop more and more complex solution and, you know, with each other with the best solution. It's also quite nice because while traditional attack defense challenges, you often don't see any score for a quite long amount of time because you want to have difficult vulnerabilities. And so the game is sort of like, you know, in a state in which you don't see anything for very, very, very long time, maybe six, seven hours before they start score. With King of the Years, you can design the game in a way that it's very easy to score at the beginning. So you can start scoring in five minutes, but then it takes a lot of time to build up and, you know, make better and better solutions. So you can keep, you know, refining your solution also after 10 hours or more. All right, so enough about King of the Years. So my challenge was a King of the Challenge. It was named Pimble. And so the original idea was to develop a challenge around the concept of code coverage. So I wanted to basically have team competing, competing in getting the best code coverage over a certain binary, okay? So however, it's a bit dry to have simple code coverage and I didn't want to have just complicated formulas that you need to, you know, to throw to a constraint solver to solve. So I team basically the challenge around the concept of Pimble, a Pimble machine. And... David, could you briefly maybe introduce the concept of code coverage and constraint solvers and the training process and all that? Yeah. Well, very simply. So the idea is that we have a binary and the binary have a certain control flow. So you have like many basic blocks, of course, that contain the code that are connected together. And the idea was that you want to reward team that are able to explore more of this binary. So to reach different basic blocks, to reach more and more basic blocks in a certain way. Of course, and that's the general idea. Then when you translate that into a game, you don't simply want them to reach all basic blocks because you have a lot of paths that basically lead to, you know, very boring checks on certain input variables. And so the idea was to do something similar. So the forces team to find a way to craft an input to reach different basic blocks. But just to focus on those basic blocks that are more difficult to reach, those are more interesting. That's why the team was this Pimble idea in which you have a RANs and you have jackpots and you have a little targets to it. And different parts of the program are associated to different pieces, parts of a Pimble machine. And in this game, basically, the idea is that teams have to meet one ball, which was a binary blob of one cubite. And it's basically a format, a special format that has its own magic value at the beginning ball. Then he has a sort of sectionedders with different little structures that define which shot you want to do. You want to hit with the left flipper, with the right flipper. You want to, I don't know, kick the table to try to save the ball and things like this. So think about, I don't know, a PE file or an L file, sort of along those ways, but it's a custom format for this game. And then the game had a number of targets that you need to hit. And it was very abstract of course. So the idea is that you shoot the ball and then there is an internal random number generator. So you will basically decide where the ball goes. And depending if it goes on the right flipper, you need to, of course, hit it with the right shot and decide where you want to send the ball. And then the different targets have different sort of mini puzzle. I don't know, you want the ball on the ramp, but you need to provide a certain input to satisfy a certain weird set of constraints. That's the idea of the game. And again, the idea was that you can score very quickly at the beginning. You just throw the ball in and you can get a couple of points. But then you immediately find out that, for example, that the random number generator is always seeded with the same value. And it's always very bad for you because every time you just throw the ball in the pinball, it just comes down exactly straight in the drain. So you can't really do much. And so the first thing you need to figure out that's the first sort of puzzle is, how do I control this so then I can make different shots and I can actually do something interesting. And so there are all these sort of internal puzzles. So for example, to do that, you need to figure out that there is a little path that if you try to shoot the ball inside the pinball with the strength zero, then it will fail the shot and then it will let you kick the table several times. And every time you kick the table, it sort of consumes some number in the number generator, random number generator. So you can basically bring it to a state that is the one that you want, for example, for the kind of target that you want to eat. That's the idea. So did you model this off of the pinball in Windows XP? Yeah, what? Nevermind, it's a bad joke. Oh, maybe people have never played a real pinball machine. You know, this is... Well, I feel sorry if you didn't. I mean, that's the only thing where you ever played is the one of Microsoft Windows. That's very sad. But anyway. It's the only skiing I've ever done is in Ski Jump. So yeah, so that was the game. You had five jackpots to eat. And if you were able to eat this five jackpot, you will get a mega jackpot. And other things, since this is a security game, is not just finding the right input to reach the different parts of the game, but there were also vulnerabilities. And the game rewards you for vulnerabilities because every time you crash the game, it gives you an extra ball. So you can play another ball and accumulate points. We're doing intended vulnerability in the games and I don't know if there were unintended vulnerability that people could actually take advantage of, but I still need to check all the solution at the end of the game, but I don't know about that. So for a total of three balls, and with three balls it was possible to eat all the jackpots as a carry and finish the game. I want to show you also that I have a visualization for that. Can I share the screen? I've been streaming the visualization the whole time, but you can also share the screen. Oh, yeah, I didn't see that, yeah. I love this interface, actually. Yeah, we've been getting mildly sick watching this. All right. So you get a bit sick if they do some certain weird moves. So yeah, indeed. So there's this visualization in JavaScript that basically shows the control flow of the entire, yeah, this is the part in which you get sick. That's the entire control flow of the application and there are these little basic blocks that are in bright yellow. These are sort of the ones that are associated to special jackpot or special moves. And here you see basically this T-deliverers, actually, one of the ball, ball one of T-delivers. It shows that they went around and they were able to eat different jackpots inside the code. It turned out that it was pretty difficult to generate this defy for the visualization because the teams got very, very good and so their traces got longer and longer. So at a certain point I had to give up because a single ball sometime it was playing for almost 20 minutes and that was not really, unless your goal is to, Duke is probably not the best thing to watch for 20 minutes. So what was kind of the factor of slowdown for visualizing over their normal execution? How fast would these 20 minutes to visualize balls take when they just? The one you're watching now is, I think it's like, I think it makes six basic blocks per second or something like this. So some traces are contained in several thousand basic blocks. So you cannot speed it up too much because then you don't see anything, it will just go too fast and you cannot just play it too slow, otherwise it will take forever. Because of course, when I tested, I tested on my ball that were optimized to eat all the jackpots. And then you find out that teams, of course, they just optimized to get better scores, which sometimes just means, for example, make a lot of invalid shots because they accumulate bonuses, for example. And yeah, they don't do anything useful, but at the end, there was a little bonus that you get every time you hit the ball. So if you just make a lot of, if you hit the ball a lot of time without doing anything in particular, which means sometimes hundreds of time, it's not very clever, but you will still get a lot of points. So they will obviously try to maximize the number of things they can fit in this one kilobyte of data. And yeah, and sometimes the visualization at that point, it gets. So in this case, for example, that's what they were doing. They were, I think, kicking the table here to try to discuss number from the random number generator that were not favorable to their strategy. So are there any strategies that you have thought of that you didn't see the teams use? Or like? Yeah, I mean, I need to now check exactly what they did at the end. I crashed at the end, so I had to sleep. And as I say, some of these traces are very long, so I need to really sort of debug it. System is all automated. So now I need to manually look at the exactly what they did. Yeah, internal strategy, of course, my original idea of the way the game would evolve actually didn't turn out to be correct at all. I was thinking that some of these problems were very easy to solve. And some of them are actually pretty hard. Eventually, teams got some hard ones, but they missed some of the easy ones. It depends. I think it took way longer than I expected to figure out this thing of kicking the table with the fake first shot. I think, yeah, some of them they didn't get it. It's always good to run this thing of the years because it's very hard to know what you can expect. They always come up with very, very strange solution. But yeah, it's amazing then to look at their strategy. For sure they score way more points without getting all the jackpot that I thought it was possible. I didn't think it was possible to score 200K points without finishing the game. Eventually they did it. I still need to investigate out, but yeah. That is awesome. Yeah, just kind of as a bit of more context for that specific statement, we expected Pinbull to last one day, one shift in our game, which is eight hours. So the CTF split into four shifts of eight hours, 32 hours total. With a rest period in between, but the players don't really use the rest period to rest. They use it to write more exploits and prepare for the next shift. We expected Pinbull to go for one shift, but it went for two shifts because it took a little while longer than expected for teams to ramp up. And they also kept going much farther than we expected in terms of points, as David meant. If you look at the graph here, it's not very complex in the sense that the entire application is about 600 line of C code, then get basically all in line in a single gigantic control flow. But there are no tricks to actually make it harder to reverse. So you can easily decompile it. And of course, there are data structures. It takes a bit maybe to read it, but really I think most of the time goes into trying to find a solution for these puzzles. I don't know. Some of the bugs were difficult to find. Some of the bugs were obvious to find, but you think, okay, that's not possible. For example, one of the bugs is that there's an array with three elements and every time you hit the bumpers, it basically saves in this array your position. And if you hit it three times, there are only two slots, basically there's a clear overflow. I think teams probably figure that out in like 10 minutes. But the weird thing is that to make one of the shots, you need 500 bytes of data. And the entire file is one kilobyte. So obviously it looks like, yeah, if I can make three, I can easily crash the system, but I can only feed two. And so then most of the time goes into trying to find a way to play tricks with the file format so you can squeeze three basically of this shot inside the same file. And I'm kind of that note in terms of this sort of file format trickery. It's a bit of a genre of hacker tricks. There's a very interesting writeup out there on the internet where someone makes an L file, Linux program that returns 42, I think, and they make it in 40 something bytes. There was an inspiration. Yeah, that was one of the inspiration for the genre. So the idea that you can overlap different data structures and you can try to reuse certain bytes from one piece of your input to actually do something else in another piece of the input. So that's really one of the core concepts, I think. Maximize your score. Awesome. Cool. Yeah, so that's the pin bull challenge. That's one king of the hill that we've discussed today. Unless, are you done buzzer up? Yep, yeah. Brilliant. There's also another king of the hill that we retired last shift, which is called Casino Life. We figured the teams would miss Las Vegas and so we brought Las Vegas to them. Eric, do you wanna talk about that? Sure, thanks. Just a second. Let's see if I can get my screen. Shared, maybe. Ah, this looks familiar. Looks like something I've been staring at for 16 hours in the last 36 hours, but I'm sure it's longer for you, Trickle. For sure. Is there, never mind. Let's see, screen. We're watching the Casino Life right now from Zardis' screen if you wanna. But I think, Trickie has some extra stuff. Yeah, I was trying to share my screen. It's complicated. Let's see. Is that, can you guys see that? Yes, if Jan used to stop sharing. We see everything, just FYI. Yeah, hopefully not, hopefully not too much. So this has been a almost year-long project in some ways because we had two challenges in Qualls that made it, that where we used the Game of Life concept. So Game of Life was originally, I guess, theoretically designed or come up with 40, 50 years ago. And since then, there have been tools around it that enable some of the rules that describe it. And Game of Life itself is an experiment that explores artificial life and how cells would replicate given certain rules. And people have taken this, of course, to the extreme. And in a few years ago, they developed a computer simulation that's inside Game of Life. And this is using the raw rules. They also implemented one using the, this abstraction called the Var Life Rules. This implementation, which was used for DEF CON Qualls, I just wanna kind of show you. So you can kind of see the breakdown and you'll see this design again in a minute when I start talking about the Blackjack game. But this is kind of the high-level view. And we'll just kind of zoom in a little bit on one pixel, what looked like it was a pixel. And then we keep going. And then literally this is, you're now looking at a single cell. And these cells, as this is going, interact in different ways. And so for example, this larger cell, this, I can't remember, 1800 by 1800, something like that size, they all interact in a way where it can stabilize or be stable or not stable, but it actually interacts with each of its neighbors on this kind of macro scale. And so the designers of this CPU came up with eight different states of this large group of cells that would make it easier, not only to interpret but and run, but to visualize and work with. Let's see if I can find real quick. So this is the memory portion of the CPU. And if one of these was enabled, which it's not, let's speed it up a tiny bit. So you can see over here, I don't have the population enabled, but there are millions of cells on here that have to interact and play with. Now, if we kind of fast forward out of that and we look at the color version, you can see up here, actually, there are eight different states that are available in here. And when you zoom in, a single cell is just one of these. So one of these was replicated before by thousands of the cells in the same game of life. One of my favorite parts when I first started playing with this, I don't know how well it'll come across on the stream, but it's just watching these different pieces flow through these different logic gates and how everything works. It's just kind of pretty and elegant. You can watch, so this first opcode, so it works on opcodes similar to most processors and the different arguments are over here and they're gonna filter up into these different delay mechanisms and repurposing multiplexers and stuff that will be filtered out so that eventually it'll pick one of these opcodes and run them. Now, for the original design, it didn't really have a mechanism for input and output. And so for Blackjack, we had to come up with a way A to simulate random number generation for the cards and then also to receive information in and out. So taking a step back, let's look at an overview. So this is kind of a high level overview of the Frankenstein that was this challenge. Each player, so I'm sorry, each team had a controller that was run by the, what should probably be named Big Ali controller. And so there were 16 of these in the cases of the teams. And so going down and each one of them would have had this communication channel where they would talk to the dealer. The blue or green, however you see the colors in here are the game of life portion. Plus there was this C++ wrapper that was borrowed to execute the game of life and to add some wrappers around it. Cause unfortunately, despite, I mean, or looking at how big this is, the execution is relatively slow. It takes about 5,000 to 7,000 generations for a single instruction. So coming down here down this path is a single instruction. And we spent some time trying to find a way to make it faster and just couldn't and ended up borrowing the code from the guys that created Golly and just tweak it to do what we needed for the Blackjack simulator. And then we just used the classic technique of throwing a bunch of cores at it, right? And then use the classic technique. Yeah, so we ended up, each one of these pictures here was either a process or a forked process. And then the dealer itself actually forked for every message that came in, it would spawn up to 16 additional forks to handle that one message. So when it went through the game of life portion, it was very, it could only handle kind of one thing at a time, but it would leave everything in a solid state for hopefully for the next messages. And then we broke out the shuffler into its own process too, because it was relatively slow. Originally we had had even the code, you wouldn't, well, you wouldn't think that it'd take too long to get random numbers and then assign them to cards. And the random number generation was pretty fast. That was done by this little guy over here that I created to, this handles, this does an XOR shift random number generation based off the seed and the seed is given by the C++ program up here. And it does an XOR shift on it. I can't remember the exact one, but to the right, eight to the left, nine and to the right, seven, something like that. And then filters everything back in. And so when the request comes through from the opcode, from the random opcode down here, when it all flows through, it releases it and it saves it in this intermediate, basically a register. These two registers, this is where it's gonna go in memory and this is the actual value that's gonna go in memory. And it would release it from there. And then we would have additional instructions that did the selection of the cards to make sure that we weren't, we had a true deck. And 52 cards was taking anywhere to find those, was taking anywhere from 30 seconds to 60 seconds and like 20 million generations or steps through this guy. So that's kind of why the different pieces are broken up here that you can see. Now, moving on to, so that was the dealer and the shuffler looks very similar. We reduced the amount of memory it was using because that speeds up the timing since you have to wait actually for an electron when it's running. One's and zero's are expensive. That's what people don't realize. We've been so spoiled by silicone chips. For sure. I mean, now this is a little slower than even what we had back when I was a kid, but. It's moving. Yeah. In a critical world with its own rules. It really is and it, you know, and it's just, it's slow, but it, it works. And it's very sequential, not parallels, not like parallel AF very the opposite. Now you can see the random number generator over here is working a little bit. And so it's working as a total side process that generates these numbers. Each time when one is used, it runs through this process and generates another one. And that was for speed, just helps speed it up. Now looking at the, let's look at, so that the reference team implementation, this is what the teams received. And this version that they were given, you can see they're missing any kind of random number generator. They have this network in and out. So when they copy values to here, the C++ program picks it up and transports it to the dealer. And the same with messages that are coming back. And these are accessed through new op codes that weren't previously available. And then that was the reference one. Now this implementation for the poor teams wasn't very good at Blackjack. It was, it would bet their bank, their entire bank role on one bet and then keep hitting until they busted. So their first task was to figure out how to keep it from doing that, how to set a value so that, how to set a cell probably over in this area that would change that from a hit to a stay, most likely would be the best way to go about it. And from there, there were other kind of possibilities. And that leads me to talking about a little bit. So this communication that happened between the controllers and the dealer had several different message types that they could use. And the first one was an init, which had an initialization and then it would send over, this is the player token I want. And the players in the reference implementation, it directly correlated to their team ID. However, it wasn't required to, it could have been any value. And then the acknowledgement would come back from the dealer with a session cookie. And the session cookie was used when they were hitting or staying. And then they could set the bet amount and they could also, they would get a result when the hand was over. So after they stayed or after they hit and they actually busted, and then if they could get different error codes. So there were several different ways that we thought that they would approach this. The main focus turned out to be trying to make the game play as well as possible. And, oh, one of the other, I'll back up another bit. So the reference implementation included this area called LifeLock, which should have had three O's in it, I think. Oh, missed opportunity. Total missed opportunity. The LifeLock portion, so every team they shared, they got a copy of the other team so they could see what they were doing, except for this redact, this part here, which would be redacted. So here's an example. So one of the teams very came up with this and it's similar to one of the approaches that I had when I was testing, moved everything out of the way and moved it up here so that it's in that, looking back kind of at the same view, it's in this LifeLock area, so it's not getting copied. So when another team tried to copy it, this is what they got, which would have none of the instructions that they were actually executing or give them any idea of how to copy it so they'd have to kind of figure it out. It doesn't look like a very useful computer to me. Yeah, it definitely is. I usually like most of the components of my computer to be connected. Definitely. No, man, it's the age of Wi-Fi. This is the beginning of Wi-Fi and Bluetooth in the game of life. Hey, I think you just invented Zardis's game of Wi-Fi life. Exactly, if you shot little gliders over to a signal. Yeah, the gliders don't work in this rules implementation though, you can't really do a glider because the rule abstraction is different. If you could somehow implement the B3S3 or whatever, but anyways, so based on some of, like in most systems, when you've got two or multiple systems that are communicating in some way and they trust that messages are gonna meet certain similarities, there are typically ways to exploit this. We didn't see a ton of the teams using this to exploit. The best teams were, had a pretty good Blackjack player. I think some of them had figured out some of the, how to predict some of the shuffling and what the cards were gonna be because they had gotten a little, they'd gotten pretty good at playing the actual Blackjack game. But for example, one of our expectations was that they would figure out that this player token could be whatever they wanted and that they knew what other teams tokens were. And so they could initialize as another team and basically do what's called spoof and spoof that player token of another team or another player and then maximize the bet amount. Or the number of players that were available, there were only 16 seats at a table. So they could send across in a NIT message that would cause it to keep going. I'm sorry, they would send over a message that would fill up basically all of the player seats before any of the other players got there. I wrote a test for this and was able to, before like kind of a normal controller would send a message, I could fill up say four or five seats. But you would take it anyway. What? Can you talk a little bit about like the custom hardware in Game of Life yet to create to do that? So I have one implementation where I don't have it here that where I did create, basically looking down here, I created hardware for that. Let's see how I can do this without, worried, I have no idea what. Yeah, let's not risk. And plus we gotta wrap up in five minutes. We have to go back to the game. I think at a high level, right Eric? So you had these sort of network protocol vulnerabilities that would require understanding how the Game of Life implementation and the emulation above that actually works together. And then you had a number of very interesting other kind of exploitation steps. We came up with nine or 10 steps in total that we expected the CTFers to play this cat and mouse game against. Yeah, there was like this cool CRC reset that they could do. So the test for this, I'd filled in this region here and when it counted up this entire region it caused it to flip the bit value, the 16 bit number back to zero. And when it reached zero, it would send a signal to the dealer saying that you need to reload this player. So this was a way that they could set this value to go off at some time and then upload a new controller and have a mid-game change so that they could say offload or figure out something locally on their machine, make some changes and upload it all within the scan of it, automated within a tick and this would fire for them. One of the custom hardware that he's talking about, I've got it slightly disconnected here but we can see over here these values, this is before it's on zero. So as soon as it started, it would start doing this and it's gonna load up here and start at the net out within the first like 700 generations instead of like 10,000 which is kind of the key to send out these initialization packets quickly. So it's like looking at the matrix, I was just being hypnotized, looking at the same. So these are delays which is here or these are wire delays that slow it down so that it would have enough time for the other network packet to get picked up before this one shot in right over it but the attempt was to make it as short as possible and so you end up with the situation where you've got different or the, sorry, I lost my train of thought again, I cannot, I don't know how you do that, Adam, type and talk at the same time when you're doing this. Like walking and talking. Oh, I've loaded it into my brain. I just, I don't even know what I'm saying at this point, it just comes out. Sleep deprivation. I expected that from Yann more than you. Cool, well, hey, since we're, I think we're at a good point here. Yep, yeah, that's great. Thank you, Tricky, for your awesome overview of the casino, I think a lot. One thing to mention about it is there's a bit of a risk with these. The exception in the stream. Yeah. There's a bit of a risk with these King of the Hill challenges in pinball that worked out more or less as intended. In fact, the teams went beyond the optimal solution. Casino life was around for even longer. And I think out of our nine steps of exploitation, the teams reached roughly step two. Two and like nine. Yeah, yeah, they kind of stumbled onto two different ones that, but there was a lot more that could have been done there. It's a bummer they didn't do it, but we'll push that to archive as soon as we archive.o.o, as soon as we get that working. Already on archive.o.o are two predecessor challenges also written in Game of Life, one reversing and one an exploitation challenge. In the latter one, we implemented a video game console in Game of Life and a team actually created a hardware mod chip in Game of Life to win that game. Very cool. And Yan, I'm closing us out with a, we have visualization running for Rob Ship AI. This is the challenge that is currently going. So the teams, you know, we're not going to go in depth about it and talk about it because it's currently ongoing, but we encourage you watch the really cool stuff that's happening in here. People in the chat in CTF discussion texts are talking about the cool strategies that people are doing. I mean, it's the level of control that the teams have over their Rob ships is really impressive. You can see people putting on their shields at the right time, shooting people, getting out of the way of other shots. I mean, it's really super cool. So it's at coreboard.com or such Rob Ship AI. Rob Ship AI was the original Rob Ship was a challenge that we created last year in which players had to do return oriented programming to control their avatars in the game. Rob Ship AI, I think we can say is an exercise in constrained artificial intelligence, extremely constrained artificial intelligence. So what they're able to accomplish with this is very, very impressive. Well, and we will take our constrained human intelligence and get back to trying to run this game. I hope you've enjoyed our time together. Yeah. And yeah, we'll see all the closing ceremonies where we announce the winners. Have a good one. See ya. Bye everyone.