So, first of all it's important to give the right credit. This research is basically James and Sergey's research. I was just as nicotine while we have like some discussions about the version and how to use that for exploitation. So, because I just as nicotine I decided that I will start first, right? So, yeah, that's really good. So, the motivation behind this presentation is basically the fact that software exploitation is not a generic thing anymore. So, we cannot talk about like a specific technique and this technique to applies to all the software. That's not how it works anymore. Software exploitation actually builds up exploitation primitives that we need to use from the target software. So, exploiting software nowadays completely depends on the software we are exploiting on the state of the software. There is no generic anymore. A modern exploitation technique such as the one that we demonstrating here will need to have some primitives established and these primitives need to exist on the target software and we're going to use that to actually leverage code execution. Also, it's important to say that a target software is more capable of computations than what it was originally intended to. Exploitation, exploiting a software is basically leveraging the potential of a target to do something else. In this case, we're going to use something that is there, but it's not something that the developer of the target software actually included there, which is deception handling mechanism in the case of GCC. If I need to resume this talk in only one minute, basically it says that the GCC, deception handling mechanism is capable of unwinding the stack and it runs a special byte code VM. This VM is to incomplete, which means that if we can manipulate the byte code, we can completely manipulate the VM and thus we can do whatever we want. We went. As Sergey and James previously demonstrated, it's possible to even write your own linker only based on dwarf byte codes, which means that you can do whatever you want, any computations you want. Great. So just to pass the theory of all that behind, how that whole history started, I will pass the talk to Sergey. Hello, I'm Sergey Bratysh and I did very little of this work. Most of it was done by James, of which he will appraise you in due course. What we've discovered is that there is a huge amount of computational power inherent in the GCC, exception handling mechanism. Travis spoke of debugging symbols. Exception handling information is almost the same but slightly different and in this difference this is where the most interesting kind of exploits lie. Think about your normal GCC built executable, be it C++ or be it C that at some point you want to propagate a C++ exception through. What do you see? There has to be a stack unwinding at some point. So there is a section in the L binary where you can hold information on how to do the stack unwinding. What you don't see is that what actually performs the stack unwinding is a virtual machine that runs non-native code that's completely different from anything native that you can find in your runtime. It's always there and it's readily invoked if all you need to do is to cause an exception. Then control will pass to the exception handler and then you can run your own byte code payload in that. In order to make this a part of an exploit, which is the part that Rodrigo helped us with, you need a memory leak or some other way to find this entire subsystem. But when you find it, you get everything. Because this system is meant for working with symbols. It's meant for finding things by name. It's meant for mapping out the structure of function frames, libraries and so on.  And we will show you that it really works and you can write it in Elf byte code alone. Now, did you expect this behavior out of your binary executable? And the answer is probably no. Right?  The answer is probably again, no. Which lets me speak of a bit of theory here. Our trust in computers is based, when all is said and done, on what we believe them capable and not capable of doing. Say I trust my dumb phone not to hijack my communications. I trust a chip to have so many states as they are able to do data sheet says. And not two more. And so what we're really doing here is when we exploit, we build execution models that exceed the expectations. And as they exceed the expectations, they perform the unexpected computation that is otherwise known as pilgrimage. I try to summarize much of the existing exploitation folklore in this term called the weird machine. So you're boring pieces of code from the target. And you are guiding them. You're using them as byte code, as implementations of byte code to which your data serves as the op codes and the mediates. And if you look at the history of exploitation that say in 2000 there were first examples of return oriented programming which didn't get called that until eight years later. But so it goes. Things get discovered in this community. Then they become a big academic item in a decade. You find your exploit in the corners of the actual system. And you borrow the functionality that's already there. Only the designers don't know it yet. In the words of Halver Flake who was there when we tried to, when I tried to summarize this heck of folklore, exploitation is setting up instantiating and programming a weird machine. So referring to the non-generic nature of the beast. Well, you have to construct those programs. It's no longer a simple trick. So a part of the target is overwhelmed by say an input you manage to send to it. And it enters an unexpected but reliably manipulable state. So if you're thinking of Turing machines or finite automata or any one of those academic abstractions, you get more state than specified in the model. You get more transitions. You get the path through those states that's not expected to be there. Could I get a glass of water? The reality of this has been that you assembled and lined up bugs that were memory corruption or an unexpected data flow. And you constructed your computation out of that using them as assembly instructions. You know, a two byte over right here, a four byte over right there and then over there. And you have a chest booster. Out of your, thank you, out of your target. Thank you. Thank you. Thank you. Too much water. Too much water. Too much water. Excellent. Thank you. So out of your target, a more powerful programming platform emerges. What we're going to do, what we're going to show you is less clever than your typical zero day exploit technique which borrows pieces of code at locations that the designers don't even know about. Or for functions that the designers even don't know about. What we do is we borrow existing functionality in exactly the state that it is already present in the program's runtime space. In particular, it's one of those things that goes into constructing the process runtime. So you think you run this binary and, you know, your main kicks in, but before that can happen. And all the wild ways happening, there are a whole lot of auxiliary computations, automata, the relicator, the dynamic linker, the exception handler. They're all just standing there waiting for something to do or doing their work when setting up or when shutting down. And you've got all of this auxiliary computation that's driven by normal metadata, by normal L-sections. You don't even have to keep them malformed. You can just put the byte code that is not expected in there and have your way with it. So this isn't rope, which was an enormously clever trick. We traced it to the hacker origins on our web page. We have some history of that. It's borrowing that's already there, that is to say, unique exception handler. James, take us to that wonderland. All right. So Sergey likes lots of high level theory and understanding what's going on. And I like understanding what's going on too. But more than that, I really like code. So let's take a look at what we actually need to do here. So all binary is compiled with GCC that support exception handling. So this is primarily C++ we're talking about. It's also GCJ and any other languages using a GCC back at LLVM and Clang or GCC compatible here. So I'm not going to differentiate that. So dwarf byte code is used for describing the stack frame layout because during an exception handling, you need to unwind the stack. And when the authors of GCC were looking at how they wanted to do that, they noticed that it was already in place for debugging purposes. So they just co-opted the same mechanism. So the process image isn't going to include a dwarf interpreter as part of the GNU C++ runtime in libGCC and libStanded C++. And we can write byte code that forces that interpreter to perform any computation. This was mentioned earlier. So basically James and Sergey, they researched that they did previously. They prove that replacing this byte code they can do any kind of computation. That basically gives them like a complete Trojan as mentioned. That does not change the assembly language of the binary itself. They prove that the dwarf is a complete environment for programming. So it can read memory, it can compute values, and it can influence the flow of execution. Of course, these are all the requirements that we went to replace our shell code with dwarf byte code, right? So this work that we're demonstrating now is intends to actually use dwarf byte codes instead of using our normal shell code or normal payload in the exploitation. So how that all works, okay? How the dwarf works. Basically if you look into the elf and the elf layout, you have like some sessions that actually call for attention, which is like the ones in red on the slide, the EH frame header, the EH frame, the GCC exception table. Those sections are actually based on the debugging format, a format called dwarf, which was created for debugging. It has a standard and it provides information such as types of variables, like back traces, and it was created for debugging and was used by GCC to actually provide the deception handling mechanisms. So the debugging frame defines how the UI process works during an exception. The dwarf was created for debugging, but then it was the same kind of standard was reused for deception handling mechanism GCC. The Linux exception handler is defined by three different like documents. Basically we have GCC itself, the implementation, we have the Linux standard base, which defines how this implementation is supposed to be, and the ABI itself. It's not exactly the same as dwarf because they added some pointer encoding and some language specific data, which is the GCC accept table header. As usual, the documentation is not really perfect. So the biggest problem is we have like one implementation and two different standards, and this is based on a third party standard. So when you look into the three of them all together, you start finding some interesting things such the caches that we exploit to actually leverage code execution use byte codes. So James, give us more details. All right. So theoretically, and this applies for both dwarf and exception handling. So we're just talking about the dwarf metadata for unwinding the stack. You have a big table, and the table has an entry for every single possible address of the program counter. And the line in the table for that program counter address tells you how to restore all the registers if an exception is thrown from that frame. You need to unwind from that point of the program counter to the previous frame. So in most cases, this is based on the canonical frame address, which is essentially the base pointer. And then most of the other registers are restored in terms of this. Well, as we'll see later, this isn't always enough. And that's where we get the real power that we need. There's would be a problem with this huge table. I just said we have a table that has an entry for every single program counter address. That's going to create huge size problems. So we don't actually have that table. That's what the table is conceptually. So the dwarf byte code is essentially a language for specifying this table in a compressed form. So here's a view of the EH frame section as it actually is, not as our giant imaginary table. So there's a call frame information section for the whole binary, and that contains a entry for every function. Now, with optimization and so on, you may end up getting one FDE, a frame description entity for two of them for the same function and so on. But in general, you have one entry per function. And that specifies all the dwarf byte code instructions necessary to compute the table I talked about earlier. One interesting thing here is that there's a language specific data area. Dwarf was made to be very extensible. It wasn't designed by any one company to work on any one software or hardware platform. It was designed to provide very general debugging support. So this language specific data area is a completely undefined area where whatever data the implementation likes can be stored. And GCC uses this to store information about catch handlers. So here's just another view of what's contained in the CIEs. A CIE is just for further compression, so information is not duplicated between FDEs. Each FDE points to one CIE common information entry which stores information that's common to all those FDEs. What we're really interested in is the instructions that are stored. So if you're wondering what the hell all this is and who came up with it and why, you're pretty much as surprised as I was when I started reading this documentation. And it turns out that the exception handling part, unlike the Dwarf debugging part which is well documented, is documented very sparsely. And you ask the community and it says, of course, you know, there was this mailing on this mailing list a couple of years ago. It explains it. But the story is that compilers use a whole lot of optimizations these days. And you don't know where your struct may end up. It may be in memory. It may be partially in registers. It may be on the stack with some of those registers saved for this reason or another. And so the designers of the Dwarf debugging format, and of course the debugging symbols are there for finding the internals of data structures and where things are and at which offsets they live and where they might have been saved, thought, okay, great. Why don't we build a virtual machine? Why don't we build this huge wooden rabbit, right? So we actually have a slide about that coming up in a few slides. Why don't we use all this mechanism to just restore state? So we need to think about what's needed for unwinding a stack frame. This big table isn't just going to have an entry that says, oh, you should set this register to this hard coded value. It's going to need to compute how to restore each register in terms of other registers and memory locations. So we end up with a machine that can read from registers and can read arbitrary memory. And I'll show you why in a minute that this is actually not only able to access data, but it's able to perform computation as well. Now there are some limitations to the techniques that I'm going to show you. We can't write directly to memory, at least not within the confines of properly formed dwarf. I've been looking through the GCC code base a little bit and they don't validate everything. So there are some semi-arbitrary memory writes that you can do if you give it some malformed dwarf data. And none of the demos that I'm going to show use that, but it is something to look at if you're doing this yourself. So isn't this nice? We have this engine inside the runtime which knows where things are, which calls on routines specially written to find them. And oh, by the way, the data it receives is always trusted. Because the compiler put it there. Of course. And it hasn't changed between now and then. Between then and now when we're running this. You know, what could be safer? We do have a few other limitations as well. We can't make, we can't call native code directly. This isn't a big limitation in terms of computation because we can do whatever computation we like ourselves. But it does mean that we can't call functions with side effects as well as not being able to write to memory directly ourselves. And our big giant table does not actually have a column for every register. It only has a column for the registers which are cally saved. So the registers that most of the time you'd really want to write on x8664, the registers that are used for parameter passing, you can't actually write those directly. So you end up having to find code sections that load those registers from things that you can control. And then returning the execution to that code section. So there is some weirdness to this programming.  If we only just showed up with an existing, here's your root. And by the way, here's your map of memory. It wouldn't be as much fun. The final limitation sounds like a limitation, but it's not really. Not through any standard process, but just through the implementation, GCC limits the stack of the Dwarf virtual machine, which I'll explain the details of shortly, to 64 words. That doesn't sound like a lot, but I wrote a dynamic linker in Dwarf that uses only 20 of these stack words. So really, you shouldn't need any more. The reason is this opcode is designed to be efficient at memory parsing. This is what your debugger uses to look into, to show you the internals of a struct. This is what an optimizer uses probably to store its state. So these are the basic Dwarf instructions. This is what I talked about earlier, with defining a CFA, a base for the frame, and it can be defined in terms of a register and an offset from that register. And then we can define the restorations for all of our other registers, either to be loaded from registers themselves, or to be loaded at some offset from the CFA. And this is all that's necessary for unwinding the stack most of the time. However, the Dwarf designers, as I said, weren't working on a particular hardware platform. They weren't working on a particular software platform. They said, what if there's some weird architecture out there where we can't just specify an offset from the frame base, and we can't just say the registers are stored from another register, what if we need to do something really weird? And we can't anticipate what that architecture is. So why don't we create a way to restore a register from a complete expression? So expressions have their own instructions. So it's sort of a sub-instruction set inside the basic Dwarf instruction set. And this is where we really get our power. We can push, it's a stack-based machine, similar to an RPM calculator, something like that. The stack is just composed of words. And we can push things on the stack, we can push constants on the stack, then we can perform arithmetic on the stack. Then we can dereference memory and push the result of that on the stack. We can read from registers. We can set up conditionals and then branch based on the output of those conditionals. In other words, we have a complete programming language living there that gets run in a virtual machine every time an exception is thrown. And of course, you ask yourself, well, where is the stack that you speak of? And it's your RAM. And you can have this machine basically work into your RAM at wherever you find the symbols pointing. Isn't that nifty? So just to bring the table up one more time, each architecture register is mapped to a Dwarf register number. These mappings are architecture specific. They're pretty well documented for the most part. There's mapping in the XA64 ABI for XA64. You can find mappings for Spark, etc. So each Dwarf instruction either defines the rules for a particular column or advances to the next line of the table. And in general, table rules inherit from the lines above them as a compression mechanism. So all this dwarf stuff is kind of cool. And when I first started looking at it, I loaded it up in a hex editor and I poked at some bytes. And after a few hours of doing that, that gets really old. I'm sure you've all done similar things. So I wrote a tool called Katana, which was inspired by Eresi, the Elf shell. Now Eresi is a great shell. It's a much better Elf manipulation tool than Katana is. But Eresi is the Elf shell. And Katana is a, it's also an Elf shell, but it's designed specifically for Dwarf manipulation. So this is showing the creation of one of the demos that I'll show later. And we just can load an executable into our shell and then you can form operations on it. We can tell it to write out the dwarf script, write out the dwarf internals into an ASCII script that we can then edit and see what's actually going on without poking around in the hex editor. Dwarf programming, compiling to dwarf.  It's a very similar to an assembly language.  And now we can have a nice Trojan. Yeah, I should say at this point that Eresi, which started as an Elf shell, has grown to be a fantastic Elf discovery project. And of course, this being the most ubiquitous binary format, well PE is a close competitor, but not all that interesting. It is one of the most basic binary building blocks of anything. And yet there is one book on linkers and loaders that explains something about it. Compare that to the stacks of books become an unleashed PHP programmer in 21 days while being a full dummy or something like that. So this format has so much engineering foresight in it, that Eresi was able to demonstrate in extremely clever ways. So I direct you to the two frack articles on Eresi, the unorthodox debugging tricks that they used. And we actually plan to integrate our tool with it, with the project. But unfortunately that hasn't happened for various logistical reasons. I probably because I got lazy. So with Katana, you can do all these cool things. You can control the unwinding flow. You can change to another exception handler, so on, so on. It's turn complete. So if we've got some function, it's responsible for handling an exception. And we decide, hey wait a minute, we want this other function to handle the exception instead. We can just set up the dwarf instruction in FDE to instead of reading the R16, which is the program counter register. Instead of reading that from on the stack, we can just set it to some hard coded value. And then the unwinding will proceed to the function we wanted it to. Okay. So far I've been avoiding talking about the catch handling blocks. And that's because they aren't part of the dwarf standard. Because dwarf was designed for debugging. And when you're using GDB or whatever, there's no notion of stopping the unwinding. Maybe you don't actually want to view all of the frames when you type BTE and so on. But that's in the realm of output control. The format doesn't have to actually specify how far you're unwinding. So here's where that language specific data that I mentioned earlier comes in. So each FDE, as well as having a language specific data area, also has a pointer to a personality routine, so-called, which interprets the language specific data area. And this is what we need to control if we want to actually redirect execution somewhere that doesn't already have a catch block to find. This is where there's really no documentation. EH frame is mostly derived from dwarf. It's pretty well documented. For GCC accept table, there are a few mailing list posts by Ian Lance Taylor. There's an old document floating around somewhere from, I believe, HP that has an outdated version of the format. In order to really see what's going on, you have to tell GCC to give you some verbose assembly and take a look at what it's actually building in the GCC accept table section. So think about packing your documentation with the source. Well, you pack it with the compiler and then it deals it out piecemeal with the assembler, with the assemble code. I'm not sure this is really the high point of literate programming, however. So once you stared at that for a while and looked at what documentation is available, you can figure out that GCC accept table is a big array of these language specific data areas. Each one has a call site table, an action table, and a type table. And the call site table just defines ranges within the function. The action table specifies a landing pad, which is where the catch block begins. And the type table just specifies which types to match when you're handling the exception. And when you look at this, what do you see? It's a complex data structure with a whole lot of pointers and linkage and walkage around it for the pointer jumping. So what if any of this data is actually corrupted? Hell knows. Because this data is trusted. It's hardly ever checked. There's so much we can do with valid data here that I haven't actually played around with corrupting it. Because really, we don't even need to corrupt the data here.  CXI throw in lib standard C++ calls into online, raise exception in lib GCC. That unwinds a frame. It calls the personality routine to process the language specific data area. And that's when it looks and says, okay, where in this call site table MI? Is there an action defined for this call site table? Doesn't the type that I have match the type specified in the type table? And if it does, then it sets up registers and returns to where the program counter was specified to be unwound to. If it doesn't, then it just goes in a loop. It should be noted that DWARF contains data structures and for representing your entire set of data types. So you're starting up from the basic integer type basic blocks. Then you can combine them in structs. Then you can describe arrays of them. Then you can describe arrays of types. It is a full description of every type with its binary representation that your program ever contained. This is really interesting because there is a lot of pattern matching that can happen there, which is again likely an exploitable part of the code. So here we see the code for throwing an exception. It's pretty simple. It's just a couple of function calls. And CXI throws what starts all the magic that then goes and runs the DWARF virtual machine. So I'm going to show a demo that we've shown before. We've shown it at Schmucon a little while ago. And this is the Trojan. We set up a dynamic linker which finds exec VPE. We prepare the stack. And we set up the registers that we can control. We return execution to a location that then loads the parameter passing registers from the registers we can control and calls exec. So let me just show you this in practice.  It doesn't do a lot. We give it something it doesn't expect. Like, let's tell it that we want a shell. OK, it doesn't like what we have to say. So I created a slightly modified version of this program using this DWARF script here that just loads the modified DWARF script, sorry, using this Katana shell script which loads the modified DWARF script, replaces the sections we care about, and saves it again. So the assembly code for our modified demo program is going to be exactly the same as the assembly code for a regular demo. So you read through the assembly code for this Trojan and you're not going to see anything that looks amiss. It never calls exec. It never calls system, anything like that. Now, let's suppose, just for toy purposes, that this is some important service that's going to run as a UID. So I can show the difference when we get a shell. So here's our Trojan program and I'm just running as a normal user. It acts normally most of the time. And this is an important point to bring up about DWARF Trojans or about DWARF exploits is that we're hooking the exception handling mechanism, which means it's usually pretty easy to end up with a program that behaves normally until we want to trigger it because usually you have exception handlers that fire when it receives some input. It doesn't expect and so on. But 99% of the time these exception handlers never fire. They're not necessarily hard to trigger, but they don't come up in the programs being used normally. So this program, which has exactly the same assembly code as before, should just reject us when we tell it we want shell, right? Nope, it gave us a shell. So we showed that before over a year ago at Shmucon and what we'd like to do right now is focus a little bit more on actual exploitation. So Rodrigo, do you want to talk about this? So that's great. So we know that there is a lot of computations being done inside this program. We know if we can control those computations, we win, right? As was demonstrated, if we dominate like the exception handling, we win. We can do whatever we want. That's great. But we also know that the exception handling mechanism was inserted when the program was compiled. We don't have control over that. We also cannot overwrite the program itself. So that's interesting for creating a Trojan, but how do we leverage that in an exploitation so we can actually abuse it in runtime in a target program? So the old GCC used it to include the EH frame and the GCC exception table as plus W, writable section in memory, okay? So basically it was possible to just overwrite it in memory if you managed to locate it. What happens is of course, modern versions of GCC don't do that. So what else can we do? So basically, we know that the Libre GCC that is inserted in the program, in the target program, it needs to find the exception table anyway in memory, right? So we know it's located there. We also know that the EH frame location is included on the frame header. So it used the DL iterate header function to actually locate it and it's located somewhere in the program, in the target program's memory. So assuming that we have an overflow and we managed to overwrite a random value in memory, we can actually overwrite a cache that just GCC actually makes. GCC makes this cache because as Sergey mentioned, the compilers try to speed up things, right? They try to do everything really fast. So there is a cache for the location of this area in memory. If we overwrite the cache location, it points, this cache pointer points to the location in memory. If we overwrite this pointer, we can actually point it to a location in memory that we control, which means that we can actually point the exception handling table and all the exception handling mechanism to actually another location in memory. So when an exception is thrown, it will execute with our rules and we win. The way that it works is basically creating a fake exception handler, right? A fake EH. We create a fake table in memory and we will overwrite the cache pointer to point to that location and then we just trigger the exception. It's important to mention that for this whole attack to work, we need to have some conditions, right? One of the conditions we mentioned is a memory leak. We need to find this pointer in memory. The other condition is we need to be able to overwrite this pointer somehow, like a write for or a partial overwrite or something like that. So those are the primitives that we need to have on the code. Main leaks are pretty common, okay? They happen very often, just two days ago Oracle released a remote full main leak that I found in XORG in Solaris. So it's very normal and that's a very common primitive that nowadays exploitation have, okay? So James, talk more about the caching. All right, so I'm gonna go through this pretty quickly because I think we're starting to run low on time. But there's this cache inside with GCC that has the program header. And as Rodrigo said, we overwrite it. We get control of the data being used for the exception handling. So I'm gonna have a little toy demo here. This isn't an actual exploited real world program. Rodrigo was working on one of those, but time got too short.  And the dwarf data allows us to use relative pointer encodings so we can actually load this data anywhere and not care too much about where that address is. There are a lot of addresses that we do need to hard code. The code that I have here is specific to particular versions of GCC and libGCC. And there are various hard coded offsets that have to be replaced when you use a different version. But they are merely specific to versions, not the randomized location and memory. Right, so the idea here is that there's somewhere on the stack that points somewhere in libGCC. And we get a memleek, we get that value. We find the base of libGCC from that, from known offsets. We know the database and then we have a known offset for the frame header cache, which is what I wanna actually overwrite. So once we overwrite it, we then point it to our data, which in this example happens to be loaded on the heap. I have a little toy program that lets us load files into memory to make it really easy for us. In the real world, you'd have to jump through a few more hoops. So let me just show this demo before it gets any later. So we have a dictionary program which allows us to load a file that it uses as a dictionary and then we tell it to look up words and it tells us the value that was associated with that key.  It has a format string vulnerability in it. Just for a toy example, that gives us a read primitive and a write primitive. And I have a Python script here which does nothing more than executes our program and gives it a whole bunch of nasty format strings. Does some arithmetic on them and then eventually gives control back to the program. This program, so for this demo, I'm not going to show running a full dynamic linker and actually finding exec and so on. We could do that, there's no reason why not, but I already did it for the Trojan case. So for this I'm just going to show that we can redirect the control flow to somewhere else. I'm sorry. So we have a function that never gets called anywhere in the program and we're going to shove the control flow over to there just through the format string vulnerability without needing a Trojan or anything. This doesn't always work on the first try, largely because of the hacky Python wrapper surrounding it. So this might need a couple of tries, let's see. So we spew out a whole bunch of gobbledygook with all our format strings and then we'll give it some input and now the function that was never called from anywhere ended up handling the exception that was thrown. Whereas normally if it got some input that it wasn't expecting, it would just tell us that it didn't expect the input. So Rodrigo is going to talk a little bit more about possibilities for real world exploitation since that's a subject he knows a great deal about. So it's important to mention as well that there is a complete paper available, okay? So we're going to give the link of the paper pretty soon. And in the paper we explained that, for example, for this little program we liquid a specific address and from this other we started getting and deriving all the addresses that we need. So you don't need to necessarily get directly the address of the pointer because that's usually very hard to locate. But sometimes there is some other registers or memory locations that are easier to leak that are going to give you enough information to derive where is the specific pointer. Everything is on the paper. It's important also to mention that this kind of technique is nowadays like if you get a vulnerability that you need to exploit in a system that is like old or that don't have all the modern protection mechanism it's going to be more difficult to implement and use this technique. Because then you need to actually write all your dwarf payload which is more difficult than just getting a shellcode or running or whatever, right? But the world is evolving and it's becoming more and more difficult to actually exploit software. So those kind of techniques are going to start being more and more important as in the 2000s when first started talking about returning to library C and ROP was first China then people started using ROP actually in 2000 nobody actually gave attention only eight years later people actually paid attention on these other mechanisms that you can actually abuse to get code execution. We showed here like when you have like a write for primitive and you just went to override to the cache pointer and then redirect execution but you can do much more like of course as we mentioned like older versions of GCC if you have a write and which means that you can write anywhere in memory that you went as many bytes as you went in the older versions you can just override to the section itself and throw an exception directly you don't need to locate the pointer or to mess up with like a leaks or whatever. So older systems are even easier to actually use this kind of stuff. You can also use like a two stage payloads. So for example, you can write a minimalistic payload a shellcode which basically will remark the EH frame as writeable again and then you just override it with your dwarf shell payload. That might be helpful to avoid filters if you want to do some complex computation on the target and there are some things being filtered rather than your shellcode you write a minimalistic shellcode that just move things around in memory. Of course you can also use like stage return to library and just basically override and do the same with the EH frame area. So those are other possibilities that are much simpler than the one we're showing here which you have a basic primitive and then you need to leak and get the information of the pointer. So more details are available on the paper. We kind of running late on time and we will be like on the QA room actually for questions. So these are the links. Katana is the tool developed by James and Sergey. It's available in Nonginu and in the GitHub you can download the paper, the presentation, the demo code and I promise I will put like a real life exploit soon over there as well. So what's the takeaway here? Let's think about this carefully. You want to trust the machines that you're forced to these days to interact with every day of your life. And in that trust what figures is how many execution engines are there? How many environments are there? How many machines are there that are programmed in strange ways and are there despite anyone working on one piece knowing that there is another that might interact with it and give you a full exploitation environment. Computer scientists have ignored this because this used to be the domain of engineers. Engineers put things together, compose and make them work. Well, now it turns out that composition can have very, very weird properties and composition can give you a much broader set of powers to leverage from a small exploit in another part. It's almost the time to start computer scientists against computing complexity. You really can't trust a machine that is made of a whole bunch of different parts that you have no idea where they take their input, how they take their input, what they can do with that input all over your memory. And that's the way it goes. You gotta cut down on this grand engineering vision of let's have everything Turing complete. Sometimes it's probably not the best idea, trust-wise. If you enjoy lending your platforms for, shall we say, unexpected computation to neighbors, then you're probably cool with that. Thank you.


Hey guys, what is up? Welcome to my channel. So for today's video I am going to be doing a review of the new NARS atomic bomb face and eye Palette also towards the end of the video. I will share my thoughts with you on the NARS full vinyl lip lacquers These aren't as new as this palette, but they are pretty new. So I do have some opinions I'd like to share with you guys. So if you're interested make sure you just keep watching All right, so let's start off with the most important part of this video the atomic blonde iron face palette So some basic facts about this palette. It came out about a week ago You can get it on the NARS website and Sephora comm right now It is a limited edition. So if you do want to get your hands on it now, it is $59 apparently it has a $155 value to it and basically it is described as a multi-use Palette for smoldering bronze eyes and cheek All right, so let's get into the packaging of this product very similar to most of the NARS packaging Just very sleek very beautiful so photogenic and then on the back you have the names It's always really hard to open NARS packaging You really gotta dig your nail in there to get it open But when you open up it is going to reveal inside two face products and four eyeshadows Really quickly as you can see you clearly have a bronzer a highlight and four eyeshadows four of these products are limited edition And special to this palette the other two are found in the regular line So the two that are found in the regular line are glop ghosts Which I actually think I do have or did have in the past and then I sold Isol de to these two are the only non-limited edition products All right, so I do have some swatches for you guys right now as you can see the first four are the eyeshadows And the last two are the highlighter and bronzer so finish wise on this palette You do have one glitter eyeshadow and then you have two metallic shimmer colors and One color that is like a matte base But with a lot of shimmer slash glitters in it and that's galapagos Then of course you have the highlighter which of course the shimmery and the bronzer which isn't matte It does have a little bit of like a sheen to it So it's not matte, but it's the closest thing you're going to get in matte with this palette So formulation wise let's talk about the eyeshadows first So these two eyeshadows right here feel like butter. They are the smoothest shadows I think I've ever felt from nars in a palette. I don't remember ever feeling it too eyeshadows felt just like straight cream they're Absolutely beautiful absolutely lovely on the lid they went on so beautiful and pigmented and that was with a brush Not my finger now the glitter color over here. This is kink um Not the best formula if you ask me what's good about it is you can get a Subtle glitter if you're not too into glitter I have that as kind of a lip topper on my lid and I think that's one of the best ways you can use this shadow So I use this as the base color and this as the glitter topper I use my finger so there wasn't much fallout and it looks really pretty over But don't expect to get this color on your eyelid to get that color You're going to have to put a glitter glue down and then use your finger to stamp it on So if you do that you won't have any issues with the shadow But it's not the best glittery kind of formula I've ever used But you can definitely make it work and I do like that you can kind of build it from something soft to something a little bit More pigmented depending how you apply it. We got as like a subtle lid color lid topper I love it and galapagos you can't really tell that it has those gold Shimmers on the lid too much if you packed it on you could tell there were gold glitters in it But as like an outer corner defining crease color, it works fine So don't even worry about that now the highlight right here, which is called last call Not my favorite highlighter to be honest from them This formula is different than their new highlighters that they just came out with Which were a lot more pressed in and I don't know they just have a complete different finish on the cheek They're a lot more blinding. This isn't a super blinding highlight Which is not a bad thing. It is buildable applying it to the cheek It didn't apply as smooth as their new highlighters It did take a little bit of building and I did kind of worry that it felt a little bit chunky on my cheeks It just wasn't as smooth upon application and it does show a little bit of texture So it's not my favorite highlighter formula But if you're using this palette, I don't mind reaching for this as my highlighter But it's not kind of my preference for a highlighter and the bronzer This is in the shade unleashed if you don't like bronzers with a bit of a reddish undertone You probably won't like this bronzer. It blended out beautifully. The formula was fine It's not as good as the bronzers in my board to plague palette. I loved this This palette has the best formula for bronzers and highlighters complete different formula than that palette It works. It blends a little bit more red toned. I don't think it's going to look very good on very fair skin tones It's going to pull very red but for medium skin tones. I think this is a really good bronzer for me It's not my favorite shade of bronzer But it does provide a lot of warmth because of that redness But you just gotta use a light hand if you're as light as me So, I mean the basics of this formulation are these are different than the new formulas But I mean, I do like it. I just think that this palette is very well suited for medium skin tones for light skin tones It works just fine. I have no complaints But I think someone with a medium skin tone This is going to be the most flattering on you and I loved the way these applied to the eyes Even this one that I kind of complained about. They're all super blendable. They're very easy to work with I just created this bomb look like I'm obsessed with this bronzy eye I have going on right now. So if you really want a bronze palette, this is super good. The quality is good It's not super unique. Not gonna lie. It's not super unique You probably don't need it. $59 is a lot to pay for a palette But the quality of this isn't going to disappoint you. This is a good palette to travel with honestly It's kind of just that bronzy look in one palette So if you're looking for that, go ahead and pick this up So now I'm going to kind of go into what I did to get this look and what colors I used So so of course to start off I used the bronzer in the shade unleashed and I belt that up around the perimeter of my face I did realize that I did pullberry red and I wasn't too too into it So I did have to take a little bit of powder to clean up underneath my contour line And then I used the highlighter in this palette last call and I just applied that to the high points of my cheeks my nose Cupid's bow it worked out very well. Not my favorite highlighter not my favorite highlighter formula, but it is buildable And it looks fine, but it does emphasize my texture a little bit. So not my favorite formula So to start off with my eyes, I started off with the bronze color and I used that in my crease It isn't the perfect crease color even though it does have a slight sheen to it. It's not completely matte It works out just fine as a Transition slash crease color and it blended out beautifully I then went in with the shade galapagos and I put that in my outer corner just for some definition again It's not a typical matte shadow, but it looks just fine nothing to worry about I then took the shade a sodie ice a soul whatever That shade right there and I put that all over my lid This is the kind of color that I thought you could only really apply with your finger to get that full pigment But no with a brush it applied just as beautifully applied like butter Love this shade. I then took that metallic shade kink And I used my finger and I just patted that all over my lid to give a finish off of glitter as a lid topper And I really love it for that I really think it's a great finishing touch to a really bronze Deep smoky eye and then I took the lightest shade for the eyeshadows an icon And I put that underneath my brow bone in my inner corner personally since I am lighter I would prefer a lighter color So I did go in with the highlighter shade But if you are medium skin tone that shade works perfect as a highlighter for your eyes and on my lower lash line I just used the bronzer and galapagos You know along my lower lash line and then I went off camera and I finished the look overall my thoughts on this palette I am so ridiculously into it. I think it's the perfect palette for summer if you're into that summer bronze look The colors in here aren't particularly unique. I definitely have colors like this. I'm not gonna lie But I just like that it's here all in one and you don't have to think about it You just know if you want a bronze smoky eye you can go for this and the quality of this is really good Definitely gets a thumbs up for me. $39 for a palette like this is pricey So it's up to you if you need it or not, but I personally am super into it And I'm glad that I picked this up. So really quickly I am going to talk about the nars full vinyl lip colors that I do have So I did pick up four and they come in this beautiful packaging with a silver topper Which is a very nice change for nars packaging There are a lot of colors online a lot more than four But the ones that I did pick up going from the lightest to the darkest we have at first sight Santo Domingo Cape Town and a Bruzzo I picked up three with that really metallic glossy finish and then one which is more of a flat color The second shade here Santo Domingo Absolutely beautiful color full pigmentation on your lips. This is the color you're gonna see on your lips So I really do like it and like I said full pigmentation the color at first sight This is definitely more of a lip topper. It's going to look good over Every lip color and give you a nice golden shift to your lip Cape Town Which is on top of the lipstick I have today. This would look pretty under a lighter lip color Uh, it kind of loses its shift with the darker the color you put on But it did put a pretty Gold gloss over my lips that I am into Like I said, I think this would look better under a lighter lip color than the one I have now and a Bruzzo This is beautiful all on its own. Oh my gosh. It's like this metallic deep rose gold almost magenta. Love this one So these aren't sticky. They have the perfect amount of pigmentation and wow I just really like the way they feel on my lips. They're very very smooth So with that being said, I hope you guys enjoyed this review Remember to subscribe to my channel and comment down below any questions you may have for me I would be happy to answer them for you. Yeah, I know I've been going kind of review crazy It's not stopping. I have a couple more reviews. I want to film and then I'll chill out a little bit Anyways, I hope you guys enjoyed this video. Have a great day. Bye


My name's David Wilkins. I lived in Bremen up on Weber Pond and lived here for 21 years. Action needed to happen here. This was a silent problem that no one was talking about, so I got involved. It's a story of finding out why there weren't L-wives in this brook in the spring. And I knew with L-wives we'd come a lot of other wildlife. I mean, when people come first, you know, I feel that way. I'm a human. We need roads, we need safe roads, but we can't ignore the silent wildlife. We need to know how to build roads harmoniously with wildlife, with the environment.  And we're trying to fix that now. We're trying to widen this out, go back to natural stream bed. That's what wildlife expects when they move through brooks and allowing the wildlife to move up like it used to. And this goes further than, you know, owl wives. There are otters that live up in the lake and they go out to the bay here and they go through the brook. They don't walk down Route 32 and so do, you know, muskrats and beavers and everything. The water mammals move through the water and so the otters will come down the brook here and as they get to the road, they'll climb up over the road to go down to the other side. Obviously risking their lives because they won't go through the culvert. That's very telling as to, you know, what we've done here. But I'm excited about this technology because it goes back to bridge construction, spanning the brook and allowing a lot of width and allowing the wildlife to move up like it used to.


Hi everyone, Shawn with jaspyscasebreaks.com here doing 2017 Panini Don Russ football five box blaster break, random team number seven where we're chasing this guy. The way this works, we had an early bird spot give away too, so if you bought one of the first 18 spots in this break, you get entered to win a free spot in the break. 32 spots overall, everyone gets a random team, no bet, common shift, so there you go. Let's do this. Here is the, it was first 18 spots. Here's the customer list and when they bought, so we're going to highlight the top 18 there. You see from Jonathan Arnaldi down to Karen Steele top 18, so we're going to copy that list into a randomizer and name on top after one of the two three times gets the early bird spot. Third and final time, Shawn Matik, congrats Shawn, so you'll see three times there, three teams on the dice. So let's copy that, put Shawn's name here for the early bird spot, now let's copy this full list back up to Jonathan Arnaldi into a new randomizer. So Shawn with the early bird spot back up to Jonathan Arnaldi, first spot purchased for the Saints, or now for the teams from the Cardinals back down to the Washington football team. Dice roll to randomize both lists and pair them up six and a five, 11 times. From Catherine down to Matthew Bloss, 11 times and 11 times. Now 11 times on the teams, 11th and final time, Panthers down to the Dolphins, 11 times there, 11 times on the dice. So Catherine Tusher with the Panthers, Zachary Shung with the Eagles, Austin Phillips with the Broncos, Catherine Tusher with the Cowboys, Shawn Matik with the early bird spot, and the Kansas City Chiefs, there you go Shawn, congrats. Matthew Bloss with the Falcons, Guy Kanashiro with the Cardinals, Matthew Bloss with the Washington and with the Baltimore Ravens, Guy Kanashiro with the Detroit Lions, Dean Sullivan with the Vikings, Guy Kanashiro with the Colts, Rory Jewel with the Buccaneers, Guy Kanashiro with the Browns, Chad Salisbury with the Chargers, Dean Sullivan with the Titans, David Razor with the Patriots, Karen Steele with the 49ers, Zachary Shung with the Raiders, Guy Kanashiro with the Giants, Catherine Tusher with the Rams, chances of Cooper Cups there, where was the Rams, right there, Dean Sullivan with the Saints, Alvin Kamara, Dean Sullivan with the Bills, Matthew Bloss with the Packers, Aaron Jones and, Chad Salisbury with the Bangles, Christopher Adams with Steelers, Connor and Juju Smith-Schuster, Stephen Fabiani with the Bears, Jonathan Arnaldi with the Jaguars, Shawn Matik with the Texans, good luck with the DeSean Watson, Matik also with the Jets, David Razor with the Seahawks and Matthew Bloss with the Dolphins, we'll pause the video for a second, open it up for trades, take a look and see, pause the video for trades and we'll be back, wait so no talks of trades, we've got a print, rip, so we've got, these are 10 boxes from this same case, it goes up 1-3-5 on the left, 1-3-5 on the right, we've got to throw a dice to figure out which stack we're going to do in this 5 boxes, 1-3-5 on the left, 4-5-6 on the right, good luck, and it's a 3, so we're going to go with the boxes on the left, these boxes here will be 4, random team number 8 which will be in the store later on, if it isn't already, so here you go, I didn't even mention Christian Caffrey Panthers, Captain Toucher, last spot he's pretty good CJ Bather of Rookie Threads for the 49ers, Karen Steele, Aaron Jones for the Packers, Matthew Bloss, John Ross for the Bengals, Chad Salisbury Karim Hunt, Kansas City Chiefs, Sean Maddock, Julius Peppers, Press Proof, Red, Carolina Panthers, Captain Toucher, Joe Mixins, Cincinnati Bengals, Chad Salisbury, Juju Smith-Schuster for the Steelers, Christopher Adams, Patrick Mahomes, the Rookies, Kansas City Chiefs, Sean Maddock David, I think your hardest part right now is that you still need Rojo and Evan, and I mean, Tampa Bay is not going to be pushing down the field at all, you know what I mean? They're not going to try to get too touchdowns for themselves, they're going to slow-trudge that ball as much as they can. I feel like even if Evan's got a long shot where he was wide open to the end zone, even he would run to the one and just sit down, you know what I mean? He's a smart enough veteran to know. That's what I was saying. I thought I was like, even if a Kelsey right now, that'd be good. Mitchell Trebisky for the Bears, Stephen Fabiani, CJ Bather for the 49ers, Karen Steele, David Johnson, Cardinals guy Ken Ashiro, Tredavius White for the Bills, Dean Sullivan. Yeah, no, I mean it's not a huge loss, but at the same point, that would have been an awesome win, you know what I mean? That's what I was hoping for. Jamal Williams, Packers, Matthew Bloss, Krita Samuel, Carolina Panthers, Catherine Tusher, Donta Forman, for the Texans, Shawn Matic, there you go. The Rookies, Mahomes again for the Chiefs, Shawn Matic, Tom Brady, Patriots, David Razer, Nathan Peterman, Mitch Trebisky, Mitch Biscuits for the Bears, Stephen Fabiani. What are you working on here? A break. You need any butter churning while I'm at this? I could churn some butter for you. You get a haircut? I did. You look sharp enough. Not too bad, right? I'm still not, I'll go soon.  Your hair looks really good, man. Literally off of a face mask. Do your fiancé do the haircut too? No. Who did it for you? It would be a barber. What's his name? Alex. What city does he work in? What's in the city of Orange? Orange, California, Orange County? What is it? Where is it exactly? Orange in Orange. The city in the county. Are they cross streets where people can maybe go to haircut from him? I mean, if they want, they can reach out to me directly. You don't want Alex making money off of your haircut? I do. But he's a particular man. I want him to be able to pay. He only wants so much money. He doesn't want too many haircuts to do. Don't look at it. Kevin, don't look at it. It's not a pure experience. What happened? I saw Edward Scissorhands in the theater. I cried. It's not real. You know the name of the family in Edward Scissorhands? No. The Boggs family. That looks like Orange County right there. It might have been. I mean, there's part of LA County that I like that too. Some real nice parts, right? That's where you live with that 1% head. Teddy's a 1%er. Who was that? Was that Jake Butt? No. Eli Manning, Legend of the Fall, Red. Oh, shucks. Hoboken, New Jersey. The Giants. Hoboken, New Jersey. And Guy Kanashiro. Guy, what's up? Mitch Trevisky for the Bears, Stephen Fabiani. Let's get the, well, let's get what we need here. Michael Cabtree to 89, 1989. Raiders Edition, Zachary Shung. Nathan Peterman, Rookie Relics for the Bills, Dean Sullivan. Leonard Fornette, Raided Rookie for the Jaguars, Jonathan Arnaldi. Did you ever throw up in your friend's closet in Hoboken? Did he go to Fordham University? Deshaun Watson. There it is. Deshaun, dude. Sean Matic. That's a big hit, man. You could sleep, Johnny Smith. Hey, Deshaun, bro. Tell him, Deshaun Watson. That's number two right there, man. Hey, Teddy. Yo. Here, man. Go. Go out there, please. All right, man. Nobody wants to celebrate tonight. Deshaun Watson is a big deal. Raided Rookie? Yeah. So let's see if we can find a regular raided rookie of Mahomes. We found Watson to the rookies inserts. Now we need to find Mahomes raided rookie. Vaughn Miller Orange. That's for Denver Broncos, Austin Phillips. Pierre Garçon. For Washington, Matthew Bloss. No, that's actually the 49ers, Pierre Garçon. 49ers, Karen Steele. David Njoku. For the Browns. And Guy Canashiro. Dunta Forman. Rookie Phenom Relic. Houston Texan, Sean Matic. And one box left. So good luck. Let's find a Mahomes. Davis Webb. For the Giants. Guy Canashiro. I was hoping Donald Pumphrey would be good. Out of San Diego State. Never made that one. Yeah, it was not very good, Danny. It was not very good. I don't think it was that bad, but it was definitely not close to what it was supposed to be. Okay, come on, Mahomes. Last chance. Kyle Giusek. Press proof for the 49ers. And we're ending it with O.J. Howard. And the Buccaneers Rory Jewel. Well, there you go, guys. That was the break. Nice to Sean Watson. A couple of the rookies, Mahomes inserts in there, but not the Mahomes rated rookie we were looking for. But thank you guys, everybody that gave it a shot. That was 2017 Panini Don Russ Football 5 box blaster break. Random team number seven from jaspyscasebreaks.com. I'm Sean, jaspyscasebreaks.com. Thanks for hanging out. See you next time.