 Good afternoon. How are we? We can do better than that. Time to go get some Red Bull. Wake up a little bit. Maybe go get some more beer. That's always a good thing. So how many people have made it over to CTF? Just go check it out, right? You should. You should go look at it. It's fun, right? Yeah. And we've heard a little bit about CTF with this giant thing earlier and you're going to talk a little bit more about this. A little bit. Good stuff. Let's give these guys a big round of applause. I sound really loud. Welcome to our talk. We're here to talk about some work we've been doing in the context of our CTF team, in the context of security research, and in the context of the CDC and open source. We're here to talk about anger and we'll get to that later. But first, who are we? Up here is me. I'm Zardis. This is Fish. Yeah. So we're from Shellfish. Shellfish is a CTF team. You can go check us out. We're playing the CTF right now on the DEF CON floor there. We're, you know, we're fighting hard. Shellfish style. As you'll see, so this talk is full of like these live demos. We're going to try to solve some CTF challenges, show how we approach CTF challenges with this sort of framework. You'll see true Shellfish style, everything melting down completely. So I'm sure there will be exceptions and sec faults and a lot of really fun stuff. But the point is something very analogous is currently happening on the CTF floor. You know, of course, we always come super like bad ass and prepared and, you know, then the game starts. Yeah. If we don't have zero SLA, then something is horribly wrong. Anyways, we're Shellfish. And we're also from UC Santa Barbara. And UC Santa Barbara, we have a really awesome HIP computer security lab. And that's where anger was created. The main people that created anger, the major contributors, me and fish, we got Relmot, also known as Andrew Dutcher. He's an undergrad currently at UC Santa Barbara. Amazing dude. We got Nesorg, also known as John Grossen. He's a high schooler at high school in Santa Barbara, Dos Pueblos High School, which is totally crazy. And he's the leadest one of us probably. We got Chris Solz, also known as Solz. Very creative. He's a fellow PhD student. And then Chris Top Hauser, known as Karius, who's a postdoc. So this kind of the anger team. As for me, I've been coming to DEF CON since DEF CON 9. I'm back in the Lexis Park. And it was awesome back then. It's awesome now. And it's kind of a lifelong dream for me to be up here speaking. This is really crazy. It was a lifelong dream for a while to even play CTF. I'd walked by the table and whoa. And now we're here. And it's awesome to be here in front of you guys. Like I said, I'm a PhD student in Santa Barbara. And I'm actually there because of CTF. So Shellfish is mostly from UC Santa Barbara. And I joined them for DEF CON Qualifier and then got pulled in and then got pulled into the lab. That was pretty cool. And I let my friend Fish here introduce himself. That's easier just grab the mic. All right. Okay, you guys can hear me. Oh, it works. Awesome. Thanks. I'm Fish. Obviously, this is not my real name. And I don't think you guys can read my real name if you're not from China. It's pretty hard to read. The pronunciation is Wang Ruoyu. Anyone not from China can read it? Probably not. Okay, you guys are honest. So I'm also a PhD student from UC Santa Barbara. And I'm a part of Shellfish, which is a super lead hacking team as Yang has mentioned several times. Super famous for everything melting down and nothing works and zero SRA. Super famous. Yes. And I've been playing DEF CON CTF for this is my fourth year. I've been playing CTF like not DEF CON but like I've been playing CTF for like six years. And I'm not a partner. I'm mostly a reverser. So yesterday I just solved my first DEF CON CTF challenge because it's a ponder ball. I just solved it. This is like the first of four years. So you know I'm very happy. And to solve the challenge I didn't really sleep last night. So English is not my mother tongue. And if I talk about some nonsense today, don't be surprised. Okay, that's it. That's a little bit about me. And I'll head back to you. All right. So here's a detailed itinerary for today. We will probably fail completely at sticking to this. So we'll go over why we need a next generation binary analysis platform, why we built it, why we're spoiler alert releasing it. Then we'll talk about what we designed it to do. We'll talk about the different parts of our analysis system. It's called anger. We'll talk about applications of it. Show off some CTF challenge solving or how to can assist in solving CTF challenges. And then we're going to talk about the open source release. I may ask, are any of you guys playing the CTF right now? Raise your hand. One, two, oh, a couple of them. Okay. So you don't want to leave before the talk ends. Unless you're not on shellfish then you should leave before we get to the live example. Okay. So let's jump into that. Why anger? Why did we build a binary analysis platform mostly from scratch instead of using one of the ones available out there right now? In fact, there's tons of them out there. When preparing this talk I went through, I saw what's our competition kind of. And they're enough to fill an entire slide. When we started anger about two years ago, there weren't this many. There are still some. But then and now in the end, everyone ends up staring at binaries in IDA. So IDA, since it came out in about 2005 or so, or hex ratio was found in 2005, IDA has been kind of the de facto binary analysis tool that everyone uses. So of course, our long-term goal is to, you know, replace IDA because it's from working with IDA quite a lot. It's sometimes very frustrating. We've all had these moments of why is it doing this? Why did they design it that way? But the truth is designing an analysis tool is extremely difficult. We're nowhere near replacing IDA, for example, but there are things we do that IDA does not and things we do and ways we do them that no other system out there is capable of. Of course, the likely situation is we'll release this and then that slide with all those names will just have one more name on it. But hopefully, we will find it useful. At least we do, so we're pretty excited. So let's talk about the fundamentals of anger. What did we design it to be like? Well, the idea is we are all Python users mostly in the lab. And let's have a show of hands. Who uses Python as their kind of primary hacking language? So anger is written in Python for Python in some sense. It's meant to be used in I Python while you're working on a binary. That gives it a lot of flexibility. And it exports its analyses which are pretty powerful in a really well designed way. We'll show off later how to use anger to quickly script symbolic execution, quickly script defining rob gadgets and so forth. And of course a core component of any modern analysis system is that it has to work on platforms other than the next 86. So in fact, by leveraging an intermediate limitation called VEX, which is how Valgrind actually works as well, we support the 64-bit and 32-bit versions of all major architectures. And after legit BS tweeted the Spark Troll tweet, hopefully Troll tweet, we even spent a couple days trying to hack Spark support into this. And it's almost there. So it's pretty extensible. So this is what a user that's using anger might see. You know, it's very easy up there. You just import it, boom, open up an example binary, and then we'll go into all of the analyses and all of the things that anger offers later in the demos. Anger has several different components. Of course, we have a binary loader that's pretty general. Right now, Alpha is our best supported platform, but we can load PE files. We can't do much with PE files yet, but we can load them and start executing until we hit some environment interactions. We, you know, of course, support Linux, FreeBSD, and binaries and so forth. And we even support firmware images. So if you have a dump off of an IOT device, and it's some firmware blob, anger can load it, tell you where it's likely needs to be loaded in memory, and you can start analyzing it. We have a lot of static analysis routines. Fish will talk about them in more detail. And we have a symbolic execution engine. And the symbolic execution engine, of course, is capable of, you know, identifying unsafe situations and reversing what input needs to be provided to drive a program down a specific path. So let's dive in. We'll start with symbolic execution. Whoa. And we're done. It's been nice talking to you guys. Sure, this is one of the first of many situations. Awesome. And now it's no longer full screen. Awesome. And, okay, we're almost there. We're almost there. Boom. Thank you. Thank you very much. That was the first demo. So let's start with symbolic execution. Symbolic execution is a concept that has been around for a little while. It's recently gaining more and more prominence. I don't know if you guys have been to yesterday's talk about symbolic execution on another analysis system. This is kind of an analogous thing. So let's dive into what symbolic execution is. Symbolic execution aims to answer the question of how do I trigger a certain path or a certain condition, right? And so you might imagine a binary that does something when you give it a certain input, like a crack me CTF challenge, which we'll look at later. And how would you interact with that? You could just give it input. You say, here's a guess. Is it good? And it'll tell you no. Because, you know, most likely you're not going to guess the flag. You can try to do some sort of static analysis. So this is what, you know, you tend to do an item manually when you're looking at a binary and, you know, clicking through here and there. And you can do that automatically, but most likely static analysis will not give you an answer because it's not precise enough. We'll talk more about static analysis later on. But for now, we need something slightly different. We need symbolic analysis, symbolic execution. And so what does that entail? Well, symbolic execution, we interpret an application. As we interpret it, we track constraints on symbolic variables. And when a required condition is triggered, when we see a path that we like, we concretize the inputs to identify possible, or concretize the variables to identify possible concrete input. Let's do a quick example of concretization. You know, if you have constraints on a symbolic variable X, and you say X is greater than 10, and X is less than 100, then you can do a constraint solve. Okay, we're back. You can do a constraint solve and come up with a number, 42. Of course, in this case, it's super trivial. In general, this is an NP complete problem and it's kind of a pain that sometimes you'll start a constraint solve and it will just never finish. That's one of the challenges of symbolic execution. And we'll go into another one shortly. So let's go for an example program. This is in Python, of course, anger analyzes binaries, not Python, but Python is more approachable. Bonus points if you can catch the vulnerability in this program, by the way. So first thing you do with symbolic execution is, you know, go line by line interpreting the program. So we hit this input, right? You see in blue the inputs have been executed. That input created a symbolic variable X. X is unbounded. It has no known constraints on it. And then we continue executing. And we'll hit this branch. And what symbolic execution does when it hits a branch is it splits. Splits into two possibilities. And so one of the possibilities is when X was greater than 10 and that branch was taken. Otherwise, it's the inverse of that. X was less than 10. And so we continue executing. Now we have two states. So keep that in mind. Symbol execution has multiple states. We'll see why that's a problem later on. So now we have two states and we hit the next branch in one of the, in the one state that is not done yet. And it splits as well, according to the two different possibilities. And so then if you want to answer the question of what does it take to print two in this scenario, right? In order to print two, we have our constraints. We have that state that, the path that made it there. And we do a constraint solve. And the constraint solve tells us that, hey, you can put in 99 or can tell you 42 and so forth. And then we can give that dynamically to the program, launch it and see the expected behavior. So let's do a demo of kind of a very simple binary that has kind of this toy back door that we want to detect with symbolic execution. This keep calm is not for you, it's for me because I did, stupidly did a, whoops, get pull right before doing this. And so I don't think it works anymore. So you might have to switch to fish's laptop. Absolutely, man. Can everyone see that? So we'll launch it. Okay. We will switch to fish's laptop for this demo. This is what live demos are all about, guys. It's Python exceptions. Here you go. So fish uses windows. I know it's embarrassing but bear with us. I mean, you know, like in this kind of situations, windows never fails. At least it's in Linux VM. It's nice. All right. Oh, yeah, by the way, Anger currently only supports Linux, but in the future it will be able to run windows. Allegedly. So this is a Anger management. This is Anger's GUI to do symbolic analysis and static analysis. So if you're going to look at this toy binary we have, that's nice for testing, nice for explaining what symbolic execution means. Let's look at it in Ida first, actually. As I said, of course everyone uses Ida, or actually we have the source code. Yeah, we do. You don't have the code. So we'll just look at it. This binary is a binary that, so here is, is it readable? All right, guys. If you can't read this, then we're screwed. Okay. So it's a very simple binary, right? It has a username and password. It takes the username and password as input, and it calls the authenticate function. If that returned one, it says you've been accepted, right? The authenticate function has a backdoor. It has a secret password. If you pass this string compare, which it has this string sneaky, then you'll be authenticated automatically, right? So it's possible to detect this automatically in Angular management. So here's the GUI. Over here we have the display of what paths are currently active in the analysis. We can actually even run multiple analyses at the same time or never just running the one. We can step these paths, and we can look at what's present currently in their registers. Presumably we can scroll somehow. Okay. In their memory. So this is what's currently on the stack. So then we can take this path, and we can step it. We can say let's execute until it branches, like we saw in the other example, right? So here we have a path that branched. And it branched for, you know, some reason, and that reason is because there's user input that was symbolic variable that could be concretized to anything. And so here we can actually look at it. We can look at this user input, and we see that in, I'm touching, all right, I'm a noob. But we can see that on one hand it concretized, the user could input any password, and it does one thing. And if the user inputs a password so sneaky, it does another. If you then look at standard output instead, and we keep stepping, there. We'll see that here where the user input so sneaky it immediately trusted him and let him in. So this is a simple example of how symbolic execution can help us analyze binaries. And then we'll go on to more complex ones for CTF challenges. So, so let's, there. Oh, come on. Why did that refresh? That was my temporary DEF CON password. It's gone. Great. Yeah, let's keep going on yours. People tell me not to use Linux for presentations, but I don't believe them. I think it's just fine. But it's dark magic. So, um, oh, it's dark now too. Great. So, uh, along with symbolic execution, anger supports a bunch of static analyses. Uh, that fish will go into detail with now. Okay, I just figured out that young has taken up too much of my time. So I'll keep these part really simple. And I'll just go, um, like talk about a little bit about it. And if you guys are really interested in it, you should come to my lab and be a PhD student. Okay, so let's, let's start. Before analyzing a binary, we also, we all need to know the control flow. If you open up a binary in IDA, what you see, the first thing you see is a property box. After you click on okay, after several other settings, you see a control flow graph. We also do the same. In our anger management, that's our GUI, um, we will show you the control flow graph of every single function, which is like, very similar to IDAs. What's the difference? Our CFG is more accurate. Our CFG has more options that depend on, that are going to adjust. And the result is our CFG is more, is much slower. Um, that is because we, we support multiple options like contact sensitivity level, support like smart backwards slicing, symbolic traversal, et cetera, to automatically resolve some, some stuff that is really hard to resolve, um, like normally or statically. For example, our jump targets. Or another example, some virtual table pointers. Well, like in comparison, IDA's CFG is less accurate. It has fewer options, but it's really faster. This is, this is how we use, uh, how we create a CFG anger. First line, import anger. Second line of Python, you create a project, the fileware, which is the binary name. Third line, you use a CFG equals to p dot analysis dot CFG. Press enter, and then it will give you a CFG. With, with, um, we want to see how many nodes there are, how many basic blocks there are. There are 78. Great. So if you want to have a faster CFG and, uh, you don't want to buy IDA, you can check out Gorsk God. Gorsk God is a, is a fast mode CFG, uh, CFG generation that does not do any, uh, symbolic solving. If there's a Gorsk God, there's also a Boy Scott. So what is a Boy Scott? You can check out the binary, uh, you can check out our project and have a look. Alright, um, another static analysis routine that we have in anger is called value set analysis. Uh, value set analysis is a kind of abstract interpretation. In case, uh, some of us haven't heard of abstract interpretation. Uh, it's basically a kind of static analysis, uh, a bunch, a bunch of static analysis, um, approaches that allows you to only execute part of the program. For example, if there's a, uh, there's a loop and it loops for 1000 times, we look in abstract interpretation, we only execute it for like three times. And then we kind of figure out the semantics of the program with only executing part of the program. So that, that gives us the possibility of actually enumerating, uh, sorry, exhausting, uh, the state space because we're not executing all, uh, all the programs. We're not ex, we're not really exhausting the state space. On top of that, uh, we can have, uh, variable recovery. We can have range recovery. And then on top of that, we can build some memory access checks and type inference. Okay. So credit goes to, not me, we take the paper and we implement them. The credit goes to the, uh, the author of this paper, which is Gogo Balakarishnan. I tried so hard to read her name. Uh, I think I tried my best. If I read it incorrectly, I'm sorry. So he's the creator of VSA, Value Set Analysis. Uh, here's an example of what, of what the Value Set Analysis looks like. Here's a piece of, um, X64 assembly. Try hard to read it. You'll have five seconds. Okay, great. Uh, I think if you, if you know assembly, you have already understand this program. And now we want to say what is the RBX in the yellow score? In the, in the yellow square. Do we know it? No we don't. In symbolic execution, as Yang said, we just keep executing it. However, there, uh, the problem is, at, at, at, um, at every single iteration of the loop, it has the possibility of branching out. That basically means we're going to face a state explosion. Oh, if you're going to have, um, one thousand twenty five, uh, twenty five, sorry, zero X one thousand twenty five different, uh, different states. If you are using native static analysis, RBX would be anything. Because, well, we are not following every single, every single branch and maybe we are only following, uh, one iteration of the loop. With the range analysis, we can actually tell, uh, RBX is less than zero X, uh, ten, twenty four. Is that good enough? Can we do better? In value set analysis, um, this is one of the value, one of the, uh, the type of the values that, uh, that the value set analysis is using. It's called strided intervals. A strided interval means a set of numbers that can be described with, uh, a lower bound, uh, uh, upper bound and the minimum stride between each single value and their size. So here, uh, these strided intervals can be concretized or, it actually means nine different values. That's, uh, at least, at least the numbers. You see, uh, between zero X one, uh, between zero X one hundred and zero X one of four, uh, the stride is four. That's what the stride means. So in this example, we want to say, what is RBX in the little square? We follow it. We follow, uh, we take the first iteration of the loop. RBX can be from, from zero to four. Take a second iteration, RBX can be from zero to eight with a stride of four. In the fourth iteration, RBX can be from zero to zero XC with a stride of four. At the fifth iteration, if you're out, oh, the loop is not terminating. What, what are we going to do? Right? If the loop is like looping forever, or looping forever, I will never keep looping with it. No? We perform a widen. And then now we think, oh, RBX can be from zero to, uh, infinite. After that, of course, zero from, from zero to infinite is not accurate enough. We perform a narrowing. It comes, becomes zero and ten, ten twenty-four with a stride of four. In this case, it's pretty accurate. We extended the original, um, value set analysis with the following two different, uh, with the following two different, uh, improvements. The first one is called, we name it as limited variable relation analysis. For example, in this case, normal VSA will be able to tell the, um, the bound of RBX. RBX should be five. What is RCX? Well, they don't, they don't do some, they don't do any relation tracking. They don't know that. We are doing some, we are doing some limited amount of, of variable relation tracking. And then in this case, we are able to tell, oh, RCX equals to RAX plus one. And RCX is six. Our next improvement is, uh, we made our VSA scientist agnostic. That is, uh, we, we included another analysis called wrapped interval analysis. So the credit goes to George A. Neves, who has the paper of, uh, scientist agnostic paper, uh, program analysis that published, uh, like in 2012 in a programming analysis conference. And with that, our analysis of binary code, uh, the precision is greatly improved. And now we'll, uh, I'll give it back to Yang and we're gonna talk about applications and real demo. All right. So all of that, uh, technical talk or theoretical talk may be, uh, a little boring, but it was necessary to get us into the actual anger application. So here we're gonna demo off a couple of things that we do and that you can do with anger. Um, first we'll demo off, uh, Rob Gadget Finder. So this isn't like a standard Rob Gadget Finder, like, uh, I don't know, Rob Gadget, uh, or X-Rop, um, that'll tell you, hey, you know, there's this gadget and this is, these are the instructions. This Gadget Finder tells you what the gadget does and then you can even filter it down later. Um, and of course, this is, uh, implemented in anger and it's super, um, easy to use. So here's the example. So we, um, load a, uh, CTF binary called Nuclear, uh, not from this, that past CTF, but from a different CTF in the past. Um, and we just analyze it. We say we want all Rob Gadgets with a maximum size of 15, find them, and we print them out. So let's, um, do, uh, that because it does semantic analysis, uh, it's a little slow. Um, so it takes, you know, about 20 seconds, maybe a little more for this guy. Um, so right now anger is analyzing every basic block and, uh, figuring out it's semantics, figuring out what registers it touches, how much it changes the stack by, um, and even, uh, where it writes to, um, in relation to, uh, the various, uh, registers that, um, it uses. So here's an example Gadget, right? It's a gadget at OX, uh, 40F4C. In this binary, it changes the stack by OX18. It pops, registers RBX and, uh, RBP and it does a memory write to this address. So this is actually, uh, on the stack. It does a memory write onto the stack, um, and the memory read from an address that depends on RBP. Um, this gives a lot of information. In fact, our next step is to implement, uh, Rob compiler based on this. Uh, we were hoping to have it for this time. It's not quite ready, but, uh, stay tuned. Um, another thing that I'll, uh, demo off is a, uh, how we would solve a crypto challenge in anger. This is a crypto challenge in quotes. It's more of a crack knee. Um, but it's, uh, a cool little demo of, of anger's abilities. The challenge is, um, from a white hat CTF. Um, it's a CTF that happened last month. Um, and then I was looking at the challenges later to, uh, see some crypto, um, and found this. Figured it would be a good example for you guys. So this challenge, uh, takes, uh, input on the command line and, uh, in standard crack knee fashion, it tells you if you're right or if you're wrong, right? And, uh, in general, if you try to guess, you're wrong. Let's open it up in Naida, right? If you open it up in Naida, if you start looking around and the binary is really big. So, uh, of course we can, uh, start, uh, drilling down, um, into, uh, parts of the binary, uh, figuring out what it might do. You know, we can, uh, decompile it and try to figure out. And one of the first things that, uh, we see immediately is, uh, it does something, um, if this, uh, returns zero, it, uh, says please check again. All right. Well, let's look at it. Um, then we see it does some complicated stuff, uh, but there's some equals equals eight. Of course from here, this is my exact process of, of, uh, solving this challenge. I figured, all right, that maybe it eight is a size. Let's play with that. So, I went, quit out of Naida, went to anger. I wrote a little, uh, so it's just very heavily commented. This is in our examples, uh, repository. If you guys want to check it out. So we, uh, opened the, the binary. Um, anger symbolic execution has trouble with certain types of codes sometimes. So, especially in, uh, status building binaries, um, I hooked them, um, with, uh, Python replacements, um, to help them along. Um, and then basically I ran it. I said, uh, I created a path group which is the standard, uh, uh, singleton, uh, or the entry point of our symbolic execution engine. And I told it to go and find, um, this point. And this is the point where we say, where it says, uh, it passes this stage and it says the input is okay. Right? And then it does some more processing and this is a pain in the butt to get through. Right? So I figured, let's look at where we are at this point. And it turned out that at that point, the key space is much reduced, the possible key space that we can make it to that point in with, and it's, after that is root forcible. So over here, I get the possible values from anger. Um, of course how to do this is all in the docs. Um, or you can look at this example. And then I iterate over these possible values with a very fancy progress bar. Uh, and, uh, test every possible value until I get the right one. Uh, allowing me to, uh, solve this, uh, crypto challenge. So let's, um, see how this goes. Run it here. So here, uh, anger is stepping through, uh, the binary. And now it's done stepping through the binary. Um, it's at this point where the input was, uh, is tested again. Um, I guess at, at this point. Um, and now it's just trying the, uh, reduced set of possibilities, which is down from, uh, eight bytes to 6,392 possibilities. And, uh, this is, it's an example guess for debugging. So just iterating through the possible, uh, keys that can even make it to this point. And try, try to find one that says success. Um, it should find it at the 80-ish percent mark. I'm actually pretty surprised it hasn't crashed yet. Boom. So we found, we find it, um, after iterating through a couple of possibilities, the flag is this. If we run the crypto, um, actually this is the input. That's the flag that turns out. If we run the, uh, binary, boom. So, um, anger is very useful for these sorts of, oh dear, five minutes. All right. For these sorts of, uh, challenges, um, I'll pass it on to Fish to look at some real world, uh, or CTF that's happening now and have her using anger for that. So one of the anger's, uh, ability is that you load up a binary, you execute arbitrary part of the code in it. Um, I had some demos for it before, I prepared like before the DEF CON. But yesterday when I was playing the DEF CON CTF, there's a challenge called RXC. And I figured out, hey, this is a really good demo for anger. And now I'm going to talk about it. So if you guys are, uh, playing the CTF right now and you guys have yourself this challenge, this is a little benefit for you. Cover your ears please. Uh, RXC is a, uh, elf 64-bit, um, binary. It's pretty big. Reversing it is a little bit hard. And we spent a long time reversing it. Before we reversed it, we got some suspected drop chains from the traffic. So we want to figure out, hey, there's a, there's a rob chain. What does this rob chain do? I mean, we can, we can, we can definitely hire a bunch of monkeys to figure it out. But we have anger. The monkey would hire would be ourselves anyways. Okay. So this is our, uh, this is our rob chain execution. Uh, rob chain execution, um, program called DRob. You pass in the rob chain, load the binary RXC, and then I dump all the rob chain on our, our stack. Uh, yes, on the stack. I create a state. I dump the, dump the rob chain on our stack, our stack. I set the IP. And then I execute it. Uh, I'm, I'm using our, one of our surveyors called the Explorer. I execute it. And then I return a run. That returns. Let's run this, let's run this program. Python rob chain.py. Okay. We, we return the first, um, the first rob chain. Um, bummer. Okay. It's called, uh, okay. It's called R. Very descriptive, uh, variable names. Yeah. There's a unconstrained path. So of course this is all, uh, it has five runs. Fairly technical, but, uh, you, you can read the documentation, understand what's going on here. And now you'll see, oh, this is where the exact, exact path that the rob chain is following. And now of course you'll have the ability to read every single state of every single program point along this rob chain, which is really easy. It can also help you debug your own rob chain and shell code, right? Alright, let's terminate this, this example. And then the next example is for the same binary. In this binary, there's a really interesting function. There's a, it does some encryption and later, later on we figure out, oh, it's T. We want to call it. We don't want to implement by ourselves because like when we're writing an exploit, implementing some C code in Python is really tedious. What do we do with it? What do we do about it? Luckily we have Python. Uh, great. So there's another program I wrote. It's really small called Collable. What it does is, um, it, it takes in, it takes in a data, and it takes in a data list and then encrypts it with the exact program, sorry, the exact function in, in that RXC program with the exact encryption function. So it, so it, you know, it has like 33 something like, a lot of code. And then you don't need to understand the encryption function anymore. You spawn up, you spawn up Python and it automatically encrypts it for you. Let's try it. Python, Collable.py. This is original data, hide Defcon, 8 bytes. And then you get encrypted data. That it all works. Um, oh, I have too much. We all support, uh, binary diffing, but in the interest of time, you can, because we have one minute, you can check this out on your own. And we'll briefly talk about the CGC. Um, the CGC as you guys hopefully know is the Cyber Grant Challenge. That's the machine, um, one of the machines that will be running the, uh, finals, um, where, uh, machines will battle each other, uh, for hacking supremacy next Defcon. Um, Shellfish participated in the Cyber Grant Challenge, uh, and, uh, we managed to qualify, what's going on? Uh, they've been no longer presenting. No, go back. This is a very clever set of slides. It's good. Alright. Shellfish participated in the Cyber Grant Challenge. Uh, we managed to qualify, putting us from, uh, just another CTF team into the richest CTF team in the world, along with the other ones that qualified. Um, with the CGC, we created a cyber reasoning system that created, uh, exploits from binaries and patched them. Um, it was very complex. An anger actually, uh, sat at the core of every component, um, which is pretty cool. So check out the system. It's a real world system with real world, uh, uses and we like it. Um, and it's open source. As I mentioned, um, it's open source with special thanks to, uh, our professors, um, DARPA with, uh, two different projects that, that anger was developed for. Um, and, uh, of course, all of, uh, you know, the contributors to anger, um, that we've gone over. Um, you can pull it, uh, on GitHub, um, check out anger.io, um, subscribe to our mailing lists. And, uh, of course we welcome pull requests, issues, questions. Um, we are hoping to make this the next generation binary analysis tool and, uh, we hope to work with you to do it. Um, anger is two years old now, uh, with over almost 60,000 lines of code, about 6,000 commits. It's a big project and we'd love to have you, uh, working on it with us. Any questions? All right. I guess no questions. Thank you guys.