virtual machines. So as you probably know, GPUs are used to accelerate graphics rendering. For instance, to play video games for design and modeling software. To play video games, that's important too. For data visualization, what you see there is an example where we show in real time about 1 billion data points using this visualization software. Playing video games in case you forgot. They are also quite good for any kind of finalizable computation. For instance, machine learning and artificial intelligence. You have here a training set that NVDI uses to train the AI for driving. Human genome analysis. High-quality 3D rendering, so when you don't do it in real time. Now for those of you who are interested in GPUs, at SIGGRAPH 2018, about three days ago, NVDI announced a new generation called the Turing. And for the first time, they claimed they can do real-time retracing. So why does it matter? Because it's actually not that new. Our friend Ulrich Repper at DevConf Tech was talking about GPUs being something like 120,000 threads that you could use at the same time. So how can you waste that much GPU power? Well, thanks to a guy in New York Quillers. You see his photo here. He's been working for Pixar and companies like that. So here is a very simple example. So this is real-time retracing. So you can see that the bottom there, you can see all the pictures. If you want to check that this is real-time, this is actual time, the clock. It's a clock you can check with your own clock that it's the right time. Now, this is pretty naive. This is something I did about six or seven years ago. You can do much better now, for instance. You can do that now. So this is the same idea. A real-time clock, you may recognize a daily work, you know, the modern clock. But now it's showing the real-time. And you can do a number of different effects, characters, landscapes. This is a realistic-looking rock, except you will see that it changes shape over time. So this is all computed. Now, this one is taxing my GPU a little bit here when running full HD. You can create moods. So all this is done in real-time. This is not a movie. You can create landscapes that have physically nonsensical features. OK, so how does it actually work inside? So the first level at the top there, the application, is going to call an API, the number of graphics API like OpenGL, Vulkan, et cetera. And then that's going to go through a GPU driver, which sends that in some proprietary format that I call the graphics bit stream on the chip, through the chipset driver in Linux in the kernel. And some graphic card is going to render that in a frame buffer, and then the frame buffer is going to be converted to a digital signal that goes to your screen. Now, the compute acceleration that I told you about, for instance, for artificial intelligence, follows a similar path, except, of course, different APIs, and you don't send the output to a screen. Now, why would you want to virtualize GPUs? Well, one reason, for instance, is compatibility. For software development testing, if you want to run a GOS, a game operating system, like Windows, for instance. For flexibility, this can allow you to have video streaming to thin clients, to this enabled cloud gaming. And, of course, all the benefits you can get from scalability, management, et cetera, for you can get with graphical devices as well. Now, in terms of large-scale deployment, this is a Titan supercomputer built by NVIDIA. So this is mostly done, most of the compute power in this kind of thing now is in GPUs. And, of course, we can have swarms of GPU-accelerated nodes. OK, so the problem is that when you want to actually virtualize this, there are many, many solutions, and it's a bit complex. The simplest and most naive one is to have a full-device simulation of a VGA class driver. So this is really how we did it in the 2000s or something like that. And the good thing about it is that it's very compatible, for instance, with old software, old hardware. And it works at Guest Boot, so you can emulate that before the firmware is even loaded. So it supports practically all the virtualization features. You can do migrations, stuff like that. You can have as many concurrent virtual machines as you want. And you can have remote access to it. I'm going to talk about remote access at the end of this talk. Now, the concept of this approach is that it's very slow, because you're emulating a device that was not designed for virtualization. It has tons of legacy quirks, like memory. It doesn't feature 3D. VGA doesn't have 3D by default. So if you have 3D, it's all software. No compositing, so no matter on desktop. And so that's basically the reason why you want to move to something else. And the next step up is to basically use a virtualized kind of interface that you're going to expose to the guest. And your graphic API now talks in sending some specific comments that are going to be converted by the host driver. So now you have the guest channel in there. And you have a virtual driver that talks to the actual driver. It's slightly more complicated. It's obviously simplified in this picture. But basically now you're sending a stream of virtual graphics comment. And the rest, the bottom of the stack, is the same as before. Now the pros of that is that you can accelerate 2D. You can get some 3D. Basically, what you don't get is specific card features. It's flexible. The cons is that you can't expose the vendor features from the card. Because now what you're exposing is a virtual device that doesn't have the actual card features. That limits the virtualization features as well. And the performance is at best medium. You don't get direct buffer access to the card, stuff like that. So it's basically, you can get multiple VMs running at the same time. But you don't get the best performance. Now when you run multiple virtual machines at the same time, there is another difficult problem, which is that you have to schedule rendering on a device, the GPU, which is not necessarily designed for that. Contact switching on a GPU is problematic. And so resource allocation is also an issue. Because now you don't have a dedicated card for one guest workload, you have to share it. And the GPU capabilities are hard to expose, as I mentioned. Migration is tentative at the moment. Part of the problem being how you feedback the screen outputs. If you switch from one host to the next, then the graphical output is going to switch from one machine to the other. So you lose some of the benefits. And remote access is a problem in this case, whether you put the remote access control in there. So the next step in order to get better performance is to do GPU device assignment. So basically, in that case, you pass through the graphics API directly to a vendor driver that resides in the guest. And now it talks directly to the hardware through vendor-specific comments. So now you're poking a hole through the virtualization layer there. Now that hole can be somewhat, you know, the safety issues can be somewhat mitigated. But that's really how you do it. So the pros of this approach is that you get near-native performance in the best case. Now you're talking to the card directly. You have good compatibility now with new features, because now you can see the card so you can know what kind of features it exposes and, therefore, switch to a more modern rendering API because you use the vendor driver in effect. So you get the latest APIs. You get the best graphic features. The cons is that, for instance, the boot console is problematic in this case, because you're no longer connected directly to the hardware.  The setup is not very flexible, because it's attached to a specific VM. And migration is a real problem in that scenario. No sharing either. I'm going to explain in a minute later why not. So the next step, to see the difference between these two cases, I have to switch back and forth so you can see because the difference is not completely obvious. But the main difference is how we talk to the hardware at the lowest level. So there, we are going to find a way to share the same CPU across multiple VMs. So in the single GPU case, you have, so that's a VGPU case, basically. We split a GPU between multiple VMs, and now that's a GPU that knows how to be split and knows how to support virtualization. So we get some compatibility, same benefits as before, but you get multiple VMs, and that's the big benefit here. Now the con is that you still don't have much flexibility. The hardware requirements are high, because now you need a lot of extra GPU power, because you are going to split it across machines. And in general, it's done in a static way. Migration and features like that are still problems. Now it turns out that when you do this, when you do this kind of device assignment, it might seem very simple. It's just, you know, I take a GPU, assign it to a VM, what could go wrong, right? So it turns out it's not that easy. You need hardware support, not just in the GPU itself, but in the chipset as well, because you need some kind of exhalation between the GPU and the memory it can touch. So you need to be able to enable the IOMMU, for instance. And then there are a number of hardware quirks that you need to be able to deal with. So in terms of topology, you have not completely isolated things like you would when you, for instance, virtualize a CPU. Now this is in a sense relatively similar to what happens with NUML when you go to virtual machines with CPUs. So what happens now is that your devices might have some sort of arbitrary topology in the physical world. And so now you can create your IOMMU groups and split them in any way. So now as long as you have a single GPU, it looks fine. You know, it's basically a straight line, so no real issue there. And if you have two GPUs that are connected to the same PCIe bridge, they can basically talk to one another. It's all within a given peer-to-peer domain and you can have two GPUs that enhance one another, can talk to one another, et cetera. Now if you have multiple scenarios like this, you're still through the same bridge. But if you have to go through inter-processor communications with QPI, for instance, quick path interconnect, then it becomes much slower. And of course, so that means it's not transparent. The way you lay out your GPU is not completely transparent and you have to deal with that. Which means that from a management point of view, devices and assignment is not something that is as simple as, for instance, allocated in memory or allocated in CPUs. Essentially, at the moment, it's rehost spinning. And this means it's not really designed or not very applicable for a cloud style of solution at the moment. And I'm talking about the case where they're not really showing. So in order to mitigate that, we want to use the Mdev framework. And in that case, you're basically exposing through Linux. There's Linux, in that case, is going to give you an interface that gives these mediator devices, so Mdev, that lets you get the kind of acceleration you need in virtual machines so that you can still talk directly to the memory of your device, but they can't override to some other location. And then you can still get it. Now, Mdev is a really complicated topic. I can't cover it today, but I invite you to look up this presentation if you want to see exactly what you get out of this. Now, the problem is that it exposes an interface that is not very easy to manage at the moment. There are things like type description, number of instances, et cetera. All this is at the moment completely vendor-specific, so you sort of have to have your management software learn the details of what's inside. And there are a number of things that are not exposed, like device quirks, driver limitations, whether it can support multiple instances or not for a single VM, these kind of things. All the stuff related to licensing is hard to manage it that way as well. So I expose a number of different ways to split your GPU. And if we try to compare them, well, we see that native GPU will give you best software availability and performance, for instance. And then you should stimulate a GPU that's performance takes a big hit, scalability takes a big hit, but again insecurity and flexibility. And so if I keep going like this and try to compare all the various cases, I see that there is no one big win. It's not like there is one that is the best. It's really a series of trade-offs. So this is why it's still very much work in progress for everybody. For instance, in terms of features, this is relatively recent announcements for live migration of NVIDIA GPUs. I'm sorry, the one before there. This is a demo. So I was telling you about the problem with migration where you see that it switches from one monitor to the next. So if you have to run across a data center in order to see the output of your machine, that's not very convenient. So another thing that shows that this is still very much work in progress is that all the resource allocation and sharing is still very much on a permanent basis. The choices are not completely set, which means rather from a management point of view, there is no single way to do it. So to take a Facebook analogy, it's complicated. Now, if you add remote access on top of this, so SPICE is a red hat solution for remote access and it tries to address some of the issues we are talking about here, notably about things like migration, et cetera. So most virtual machines are used remotely and so when you connect to them in a data center, you're going to basically get a stream of video updates. Now, this enables a number of use cases like cloud gaming. You can stream high quality 3D to your phone, for instance, because H264 and streams like this are completely asymmetric. It's much easier to decode than encode and so you can have a big heavy machine that does the encoding in the cloud and then a lightweight machine on the other side for visualization. So this means you can bring your work environment to any devices. It has many nice features. So for KVM users, the solution for to get this kind of things is SPICE and we're working on making SPICE basically streaming capable like this. So to explain a little bit the evolution compared to what exists today, you can have multiple ways to do remote access. You can do it either from the guest or from the host and the historical solutions would be sending 2D comments basically too. So they will intercept drawing comments somewhere and send them over the wire, random them on the other side. Now you can intercept them in the guest and that would be typically for Microsoft remote desktop or these kind of solutions. Or you could have, in the case of SPICE, the SPICE server do it for you in which case you get the remote console as well for your VMs, et cetera. For video streaming, it's more or less the same idea. You can do that from within the guest or you can do that from within the host. I'm going to show the trade-offs in a minute. So what happens when we do this is that instead of sending graphics common in a device specific format like we did before, instead we are going to switch to network kind of graphics. So if we do that from the guest, for instance, if you were using terminal services, you would use something like that where there is in the guest some kind of software rendering stack and then it sends the data over the network and you're basically using the virtual network the normal way. Now, when you do this, this is widely available. Most operating systems now have this and it may be as simple as X11 in the case of Linux. It's transparent for most users but of course it only works after the guest has booted so you have no console in that case and it does require that the guest network works. Now, why is it important? Because in some cases you may want your guest to be something you can access remotely, graphically to do something but that the network is not going outside and you want the network to stay constrained inside the VM. And so that's why we have also host-based remote access in which case, so in the case of Spice we have a Spice server component that will do the encoding and the way this works then is that we have basically a driver in the VM in KVM basically that is going to intercept 2D comments and behave mostly like a VGA then transmit that to the Spice server, Spice server sends that over the network and you have a Spice client on the other side that renders that as graphics. That works pretty well for 2D but it doesn't work very well for 3D. So if we want to do 3D we do need some kind of streaming so something that looks more like we have an encoder that generates video on the fly. Now, if we want to do that with vendors like NVIDIA they really insist on doing this in the same way as is being done for virtual GPUs and so remember that in the VGPU case what we had was that the GPU driver resides in the guest. So that's why you need to do the encoding as well. So that means basically that your encoding H264 from your frame buffer within the guest which means that you need in the guest some kind of agent that is going to send the data over and you send it to the other side over the network. So this is a little bit complicated to set up and it has the same kind of drawbacks as we had before because now you have to wait until it's booted and you have to have an alternate solution pre-boot that shows you the console before it boots. And so finally something that is not done yet but I hope that it will happen within maybe the coming year or something like that is to do host side streaming still using hardware acceleration and so in that case what we do is we send the graphics down there and we still have the splitting abilities that we talked about before with the GPUs. Now we're using the VAN.GPU driver here and we do the encoding host side meaning that now the whole network stack happens here. Now if you do this that way then the nice problem that you have in these cases that you need to find a way to share the features, share the encoder, share the frame buffers, et cetera. Now why is this a problem? Because now your graphics API is doing the rendering in this side, right? So it's doing basically all the rendering is done in the guest and you need to find a way to pass the guest data preferably without copying it in a way that the host driver can see it. So there are some developments that are going on in the Linux kernel at the moment to try to enable that but it's a relatively complicated problem and so you have to realize that for instance the rendering may happen at 60 or 120 frames per second so you need to be able to pass the data from the guest, I did a guest user space down to host kernel without copying it. So that's pretty expensive. And I'm actually done and I spoke too fast. Sorry, I'm out of time. I removed a number of slides compared to, yes. It's not again. It's fine. Thanks for the presentation. I wanted to ask, because in the Kubernetes community, whenever you request a GPU, then you get the whole GPU and sometimes you might not utilize the GPU fully, right? So it's very interesting the work that you're doing here with splitting GPUs. So this VGPU, if I wanted to try this out, where would I find this? Okay. So some of the stuff that I showed is actually working today with, well okay. When you say you want to try it out under which kind of conditions do you want to try it out? Like I want to download it. I want to install it on a three-node or five-node Linux cluster. This is for experimental purpose. Not production kind of use, right? Yeah, this is, yeah. Probably going to be experimental, because the part of utilizing GPUs in Kubernetes is that limitation of not being able to split how much resources. If you want to request how much CPU you want, you can do that, but you can't apparently do it with GPUs. So at the moment, this is still a lot, very much work in progress. So if you want to have VGPUs... Oh yeah, okay. So Nvidia VGPU is supported in REL75. So if you want to play with it, I think you could with CentOS, but you have to buy the grid software from Nvidia. Yeah, but it's supported as I understand today, it's supported in queue configurations today, so one-to-one. So it means it can't split, I think. No, it supports VGPU, but not with Spice yet, that's all. Okay. Yep. So it's supported with REL75 and with Rev 4.2, but I don't think you want to set up Rev or Overt. So you just have to get the grid 6 software from Nvidia. So there can open source alternative like OpenCL right now? No, so at the moment, as far as I understand, none of the VGPU capabilities that Nvidia offers are supported by Nuvo, for instance, if that's what you're asking. Like, yeah, or OpenCL, it's an alternative to Nvidia. So for OpenCL, okay, I would need to check because my understanding, so apparently my understanding and Karen's are different. My understanding was that at the moment, Nvidia was still offering only one queue, well, basically whole card configurations and that the rest was still unsupported configurations. Karen says otherwise. So I think I'm probably wrong on this. And maybe this is only for remote viewing. Now for compute only in full open source, I don't think there is anything that works. If you want in full open source. So Intel is also working on VGPU. So KVM GT, so that would be fully open source. Okay. There's another question in the front. I understand why the streaming agent approach is not ideal, but are there any open source streaming agents I can use right now with Overt, Slash Rev, or with KVM and Libvert? So the streaming agent itself is open source and it's basically built so that there are plugins in which we are trying to open source because they use APIs that are normally public. So there is no reason we could not open source it, whether it's still under discussion whether we can actually open source that or not. Now the fully open source one does not use a hardware acceleration, that's the problem. So it basically does NJPG and coding and stuff like that which is only software. So it's good for testing purpose but it won't give you the hardware acceleration. It will give you hardware accelerated rendering but not encoding. Okay, I mean I know that Spice does NJPG, is that part of the Spice like Agents and all? Yes, that's what I'm talking about. Yeah, it's built in the Spice guest agent right now. And now there are other, you can of course use other solutions like BNT or like GX or whatever. So if you use BNT for instance, you will have very fast rendering on the counter but you will get very slow transport over the network. Okay, and there's lots of proprietary streaming agents though, I guess. Yes, as I'm sure you have, GX is an example. Okay. Any other questions? Thank you. That is another one. So assuming there's three hardware vendors, you know, NVIDIA, AMD and Intel, do you have to buy professional graphics adapters for virtual GPU including Intel, do you have to have like a Xeon and all? Okay, so as I mentioned in one of the earlier slides, so in order for this to work, you really need good support for IOMU. From the card side, it really depends on the vendor. Each vendor has a different approach. So for NVIDIA, you typically want recent cards to get VGPU, you really need cards that are dedicated for this. For historical reasons, AMD used to have the IOMMU support baked in earlier. It doesn't necessarily mean it's better supported in Linux but at least from a hardware point of view, older card have better chances of being isolated. It doesn't mean that the driver support is good. So for Intel, Intel is working a very open source way. So their own approach is from a software support point of view is nice to have. The problem is that the performance at the moment is not the best among the vendors. Yes, okay, but are those hardware features only in the quadros rather than G4s and only in the radian pros rather than the radians? Yeah, so as Karen said, it wasn't that. It's specific software. At least in the case of NVIDIA, it's a specific software license, so the grid software. And basically, in order to activate that, you have to talk to a grid server, the third software, you have your license for this or that configuration. So it's not just the hardware. Okay. It's also a software license. And there is also a specific grid SDK that lets you take advantage of some of the features. So for instance, I was mentioning that we're using public APIs for the streaming agent. That's part of this grid SDK, for instance. So APIs like how to capture the frame buffer, how to stream it, and code it, stuff like that. Looks like we are out of questions. Thanks a lot for your attention. I'm sorry for talking so fast.


Hello people of the internet. My name is Johnny and welcome to a very late upload. It's currently 10 a.m. I was lying in my bed getting ready for an early bedtime tonight and then Jason Blum had other plans. So this is gonna be a very late upload for FNAF news though if you are watching this as soon as it comes out that's how I know you're dedicated to staying up to date with everything going on with FNAF. And if you're not one of those people but you wanna be included in that group feel free to scroll down, tickle that subscribe button. We talk about FNAF news all the gosh dang time but we're not only here today to talk about the FNAF movie. We've got a whole bunch of other reveals on Daco's recent charity live stream. So we're gonna be talking about that as well as a whole bunch more stuff. So let's not waste any more time. Once again, scroll down, tick that sub button and let's hop right into it. First up for book news, we've got our first preview for the upcoming Fazbear Frights graphic novel collection volume four. We got a few panels for the upcoming adaptation of the breaking wheel which is a very interesting story to adapt because if you've read that story you know it gets very gruesome very quick. So I'm gonna be curious to see how exactly they decide to adapt those elements from the story. In this first look we meet our main character Reed I believe as well as the twins of Shelley and Pickle. The book so far will include the stories, the breaking wheel, the cliffs as well as Sergio's Lucky Day and it's gonna release on December 26th of this year. Moving on now to some brand new YouTube news. First up we got Daco teasing his next figure which I believe is like his fourth figure which is crazy. This is the concept art for Puppet Daco not called the Puppet Daco which is a little disappointing. Though of course the Puppet the Puppet has been a long time running meme in Daco's community. Of course now he's taking on the appearance of the Puppet. He's inside the gift box. He's also got a Chibi Freddy plushie and soon to be as well a Chibi Bonnie plushie poking out from the box as well. No release date for this exactly just yet but Daco did say it's gonna be coming out pretty soon. For some brand new plushies we got two teased. First up we got Sitting Montgomery Gator. Seems like U2s is gearing up for another release of adaptations of their previous plushies. You can see right over here. They've got the back of Sitting Monty. They did also reveal that they gave him pants this time cause a lot of people pointed out his figure did not come with pants so he was a bit naked there. And on TikTok they also showed off their upcoming Sitting Roxanne Wolf plushie which looks absolutely adorable. Not entirely sure if I'm gonna be picking up these brand new sitting plushies because like I said I've already got the originals as adorable as these guys are. I ain't all I'm pretty expensive to get duplicates. But I'd love to know what are your thoughts on these brand new reveals from U2s for plushies as well as Daco's next figure. Moving on now speaking of Daco's charity stream once again he showed off three amazing brand new looks at upcoming Hex products. First up was the prototype for withered foxy like I said keep in mind this is a prototype so stuff's definitely gonna be changing before the release. For example, Daco mentioned they wanted to make the hook a bit smaller as well as change up the structure of his snout the marking on his face, you know the chest area. So definitely still a lot of things they want to adjust with this plushie but honestly it looks spot on to withered foxy already. Next up they showed the prototype for withered Bonnie which as you can see features a detachable face plate so you can choose if you want to display your withered Bonnie plush with his face or without his face like we see in FNAF 2. Once again this is another prototype Daco mentioned for changes. He wants to change the amount of wires as well as their length coming out of his arm but from the looks of it these withered plushies are turning out perfectly. I was very surprised at how well they've adapted these very complex designs into plushies and speaking of complex designs being turned into plushies this is the concept art for the Hex Springtrap plush. Daco showed this to me a couple of weeks ago and I was and still am absolutely blown away by what they were able to achieve with the concept art alone. This guy's definitely not gonna be coming out for a long time but I really hope they can nail the plushie cause once again the concept art has blown me away.  Once again I'd love to know what are your thoughts on the prototypes for the withered plushies and how do you feel about Springtrap's concept art. Taking a quick pit stop at Popgos because Popgos as well got a whole bunch of reveals over on Daco's charity stream. First up we got a brand new phone case for Popgos Evergreen inspired by the tape recorder as seen in Five Nights at Candy's Three. Definitely a surprise announcement was not expecting a collaboration between these two titles but it is absolutely amazing to see. It also plays music when you toggle between the room and vent cameras which is just an amazing touch. Next up we got the reveal of a second Popgos U2's pin set. This time based on the Halloween costumes the characters are going to be wearing in the trading cards in Evergreen and something extra special about these characters is that Popgos, Skeleton Popgos actually glows in the dark. No exact release date for these guys just yet but it seems like they're aiming for a spooky time release. Thirdly we got the reveal of the car park camera in Popgos Evergreen featuring Stone the Crow as you can see. Very cool thing about this camera is that it will be changing the time of day as you view it throughout the game. This is going to be mostly noticeable in endless mode where you can see the full 24 hour stretch from sunrise to sunset. Take place throughout this camera. That's going to be amazing to see and it's an amazing environment. What can I say? Still just blown away by how realistic this camera looks. I mean, Cain and the team, you did a fantastic job.  This is a full look at his model and Jesus Christ, he is terrifying. There was also a surprise jump scare that Docko got while viewing the model of false balloon boy which was absolutely terrifying and also very amusing to see Docko get scared by cause it was very frightening, like I said. If you want more info on the brand new Popgos reveals in the charity stream, there's going to be a link down below to Cain's video which shows not only Docko's reaction but a bit more information on each reveal. And lastly for Popgos, today is actually the anniversary, the seventh anniversary of the series and in celebration, can release some brand new wallpapers. The first one we've got is of course the brand new revealed false balloon boy as well as false Freddy. And now, whew, let's talk about the movie. Couple days ago, people were able to find out that a second trailer which had a runtime of two minutes and 25 seconds was rated in Finland. Now, some people were skeptical about this news. It was the same length, about the same length as that leaked trailer we got, about two and a half minutes. So people are thinking it was going to be that but again, this was only one report. It was in Finland of all places. You know, no disrespect to the people living in Finland. But then just now, we got some custom FNAF Twitter hashtags and this was big. I mean, not only do you have them showing up for Freddy, you know, FNAF Five Nets at Freddy's movie, you've also got Bonnie and Chica and Foxy and fricking Mr. Cupcake as well. So something big was going down, something big was coming and lo and behold, a couple minutes later, Jason Blum tweeted out this. Buckle your seat belts. Tomorrow is going to be a big day at FNAF movie and then all the brand new hashtags. So the second trailer, the first full length trailer, because you know, as opposed to the teaser video, which was only like 40 seconds, this is a full two and a half minute long trailer. It's real and it's coming out tomorrow. Now, when Scott actually replied to all the drama because of the leaked trailer back in May, this is what he had to say. For those of you who resisted watching it, I think you'll be much happier when you're able to see a finished product that is edited and polished with VFX and proper sounds. And like I said, because this brand new trailer is about the same length as that leaked trailer, a lot of people are thinking this is the finished version of that trailer. That's really all we know right now. I'd love to know what are you hoping to see in this brand new trailer and that is going to do it for this FNAF news video. Of course, like I said, subscribe so you don't miss out on when that trailer gets posted because you bet you will be doing a reaction and analysis to it. But thank you all so much for watching this very late upload for FNAF news. Hope you're all doing well and get hyped, FNAF movie is coming soon.


Cool, so to recap our discussion. There's gonna be no midterm review. The midterm will have questions on it You'll be expected to answer those questions Hopefully you can infer from the material. I like that you can find vulnerabilities So you should expect to be able to read code and talk about find vulnerabilities know the different kinds of vulnerabilities what they're Big capabilities they allowed why they're vulnerable all that kind of stuff, right? Those are the important things everything we've covered up until after today is fair game Any other questions? Let me Yeah, it's a weird button that only sometimes works Okay, so I'm actually going to skip a lot of content. So there's about We're gonna go over loop overflows which are really important And then we're gonna go over format strains and then we're gonna look at defenses against these binary Exploitations that we talked about so for those of you who are You know doing the levels there may be some of the levels have to relate to some of the things I'm skipping but only definitely after 10 that correct. Yeah, that's correct So don't worry, you know, you want to stop at 10 stop there the slides are still available They're still in the slides. They're just hidden so you can easily see that content and you can Go look and learn and all that fun stuff. So questions on All right, let's get into it. Okay So we saw on Wednesday, right? We saw loop overflow vulnerability. So we saw We saw index Overflow right or you can pull the index so you can overwrite any relative address from an array Right. So in loop overflows. So I do I mean that we're overflowing a Loop and a for loop or a while loop The code of the loop Right, so yeah, so not doesn't mean you're not overwriting the loop, right, but we're Controlling the loop iteration right how many times does that loop iterate and so if we can do that We can often have a security vulnerability And a very special case of this that happens often Is no didn't stop Can't stop won't stop. All right, but my clicker won't work Unplugging it and play this is actually hilarious. I don't want to go didn't do it. Okay. Wow. That's crazy There's only two difficult problem with your science Naming things fashion validation and off by one Right so Wow, that was got a terrible response You're not having a midterm today, so you can relax a little bit laugh Okay, so what's an off by one error in a loop? What does that mean? Yeah, so we're we're looping through something over the length of something and we should be doing less than length Right, but if we do less than or equal to the length that allows us to go one extra Right, so we're looping our loop iterator is going one more than we expect similar to array overflows right in the sense that We're going past the bounds of the array But the key thing is that oftentimes we're only one we can only go one element above that array right and so These are very tricky because oftentimes the program will not crash when you do this Right, it you may have to wrangle the computer to make sure that you can actually do what you want it to do So what's so if we think about there's a buffer on the stack, right? It's I don't know. It doesn't matter the size. What's it's the only variable on the stack What's right above that buffer of the local variables the save base pointer, right? Yeah, so an off by one error, right will allow us to go to the array and go one above that that saved One above this loop, right So we can maybe modify either depending on the size of the data We can modify you at least significant bite, which is usually the case because we're talking about character buffers or the whole thing So there's a really good paper You want to get more in depth into this frame pointer overwrite Reading this paper So let's look at an example to see exactly what happens So here we have some function. It's got a 256 white character array It's got an integer I It has a for loop. So this for loop is going from zero to two fifty six It's setting the I element of the SM Array that gets passed in copying that to buffer I and then it's quitting. So what essentially is this I mean Actually, I guess this is better. It's essentially a men copy, right? So we're moving memory 256 bytes Well, actually we want it to be 256 bytes, right from SM to buffer Right, that's what the developer wanted to do. So if we look at main we say hey, you know You got to make sure you pass those two arguments and then we call this function with argv one and then we return Equal to right in that in that loop iterator, so how many times is this loop going to execute? 257 times right Which is what makes this really really tricky to look at and just eyeball and see yeah, there's definitely a vulnerability, right because Less than or less than or equal is very slight plus. There's not the number 257 doesn't appear anywhere Right, we have to know that based on some man takes up the looping and our experience before loops and our experience of knowing that I'm showing you an example that's specifically about this type of vulnerability, right? So the question is Can we So Here at this point so at this point where it's gonna do this copy What's the stack looks like so let's assume that the variables are in this order as they appear So first there's buffer and then under so underneath the first variable on the stack, right local parameters It's gonna be I and then above that is 256 bytes. So 256 characters. So then what's above that? The saved base pointer and then what's above that above the save base pointer Instruction pointer. Yeah, the saved instruction pointer and then what's above that? SM. Yeah, exactly the argument SM Right, and then above that is mains locals and mains all that main stuff, right? So if we go buffer plus 257 are we gonna get to We'll get to the base pointer or can we overwrite that whole thing why not The size of the character, right exactly so characters only want a Eight bits wide right one bite.  So we can't change instruction pointer We can't we're not gonna get there I concur, okay, let's look so this really has to do with the function epilogue. So what's the normal function epilogue on x86? Leave and then read. So what does leave do? Yeah, so it actually does two things, right? so it first so We got to remember our base pointers Somewhere for our current function, right? So we know based on what we just saw There's gonna be I and then it's gonna be the buffer And then the save the base pointer is gonna be there right at where the save base pointer is and above that's gonna be EIP So the stack pointer is gonna be somewhere Down farther right because we allocated memory when we called this function Right, so it leave has to do it first has to essentially deallocate by moving the stack So it first does a move The base pointer into the stack pointer so make the base make the stack pointer point to wherever the base pointer is Then it does pop EVP. So then it does restores the base pointer that's saved on the stack So in these examples I'm gonna explicitly write out these two instructions. So these two instructions move EVP into ESP Moving the stack pointer up to where the base pointer is and then pop EVP pops that value into EVP So those two are exactly equivalent to the leave instruction But I'm writing it out here so we can see exactly what happens and then what does Rhett do Yeah, pop EIP essentially right or start So get that value on the stack and start jumping to it and also move this stack up one It should be the EIP that's saved when you call the call function or the call instruction right if the call instruction pushes a Pushes the next instruction that would have been executed onto the stack That's where the save EIP comes from. So there's pop EVP, right? Put store EVP in EVP Then that pop move the stack up. So Rhett So now with the stack of point two is the save instruction pointer and then Rhett jumps to that and moves the stack up Cool. Okay, so let's look at this. So we have a stack pointer So these are registers right the stack pointer the base pointer and the program counter or the instruction pointer Right, and so we're kind of doing this a little bit more symbolically So hopefully it should be a little easier to understand. So The program counter is now at this instruction, right? So we haven't actually executed this instruction yet so Question you should some of the things you should be able to do right look at this function and write the stack That the function should have at this point right so we saw that There'll be an integer I then there'll be buffer, right? So these Here even though these are look kind of wide. Well, these are actually each one bite. So this is not going to be the whole Objects are not drawn to scale, right? Exactly there would be four on one line, right? But it's a little harder to see that and then above that buffer, right? So the end of the buffer is buffer bracket 255 That's how to get to the final bite of the buffer and then right above that is going to be the saved EVP And then above that's going to be saved EIP and actually if we go up we can see that main doesn't Didn't have any local variables. So right above that is going to be Actually, this is wrong. There'll be Saved EVP of mains caller and saved EIP of mains caller and then the argument but also yeah, the parameter sm is also missing What are you gonna do? Yes close enough for me Okay, so we know so base pointer, right? So we know that the base pointer is gonna point here Right because we reference all local variables by negative offsets from the base pointer Which is gonna go down and we reference parameters by positive So it's gonna go up to reference the positive arguments and so from looking at this we can tell that okay This is mains function frame and this is Sorry, this is function Clunks, I gotta use a different name. This is funks function frame, right and above that is main And we also know that the stack Points to here. It really doesn't matter exactly where the stack is but we know that the stack is going to be below EVP so What's going to happen? How does this diagram going to change based on executing this instrument? Save EVP, right? They're going to both point to the same place, right and now Essentially all of this has been freed in some sense, right? So it's grayed out because it's Freed from the program's perspective, right? But those memory addresses are still there We didn't change what's in those addresses, right? Oh, did I go too far? Okay. So then what happens in the next instruction? But we haven't done the copy. We're at the end of the function right here Just normal stepping through this to understand exactly what happens. So then what happens here? What happens with this pop? So EVP is then going to point up Right, it's going to point somewhere up here to mains base pointer Whatever that value that was in save EVP is now going to be where our base pointer points to Cool. What happens to the stack pointer? Do they ring the same? Somebody argue one way or the other? Yeah, I thought you're raising a hit It's going to pop, right? That's it pushes and pops change Change the stack pointer, right? So at the end of this the stack pointer is going to move up one So it's going to point to the save vip All right to make sense because we've just gotten rid of the save base pointer We save this base pointer so that we could use it in funct Or we could that funct could use its own base pointer and then when we're done We want to go back to main so we want to get rid of that memory So now that we're in here EVP is going to point somewhere up here Not exactly there and then stack pointer is going to point to the instruction point And then so now what's going to happen when we call ret? Well, we return Yeah, pop eip, right? So it's going to take this saved instruction pointer value start executing there And then it's going to move the stack pointer up one, right? So it's going to go to main All right remain doing something and then it's going to call Return zero so the stack pointer is above the save vip and the base pointer is somewhere above that And so from our function, we know we call this funct and then we return immediately, right? Okay Yes Okay, so now so in this diagram, what can we Change with this off by one overflow save evp. So what can we control the whole thing? Just one byte exactly. So when our program accesses buffer 256 It's actually referencing this byte on evp Right, and so depending on the end in this x86 this is going to be the least significant byte So we can control the least significant byte of evp Okay, so let's think about What that gets us right because if we go back here Well, if we control the base pointer Then what let's say you can point this base pointer to anything, right? Did that change anything here? Right, so we control the save base pointer So now at this when we do pop evp now evp can point anywhere But does that get you anything here? Yeah, but right here right with function and functions epilogue Normally on a normal buffer overflow, right? You have at this return instruction you control the save evp so you can make it go wherever you want right And this ret instruction transfers control from the program to your shellcode, right? That's what you want But if you've just changed this base pointer ret still happens exactly how it would happen Right, and you're going to go back to main and start executing main Okay So our goal is we want to see what we can do by changing this right but just changing evp. What can we do? so Let's try to track it. Okay, so From the epilogue right so we're moving the base pointer into the stack pointer right so so this is Any epilogue function epilogue moves the base pointer Into the stack pointer. So this now changes the stack pointer right before it's going to do what? Pop evp and then what return right? How does it know where to return to? What register does return implicitly use? How does it know what this where the saved instruction pointer is? The stack pointer yes because where the stack pointer is pointing to at a return That's where it's going to go jump to What are we controlling in this instruction? What happens here? Where does what happens to the stack pointer? It goes to wherever the base pointer is pointing to right So now what if we control this base pointer? Now we control the stack pointer And now when we do pop evp Something about choosing is going to be popped into evp Right, so now the the stack pointer is where evp was our frame pointer plus four bytes to move up four bytes Now when we do a ret now what happens goes where the stack pointer is And is going to take the value that that stack pointer pointed to you put it in the ip start executing from it and move the stack up one so Right, so now the original program counter basically references the original frame pointer the evp right plus four bytes Do you see how so if we control this base pointer? We can arbitrarily control this base pointer We can influence what the stack pointer is And then where the program returns from but we can't do it in the function where the overflow occurs right But function is called by main And we can control mains essentially when function is called when f UNC is called We can control main's base pointer because when function leaves Calls the leave and return it's going to set up names base pointer And then when main does this right main has an epilogue. It's going to do this exact same thing It's going to move the base pointer into the stack pointer And at this point now we control the stack pointer because we control the base pointer And then it'll do pop evp and then a return so as long as we make sure that whatever value we put inside evp if Four bytes above that is the address we want to jump to then the program's going to jump to where we want it to go And so this is how we can use this so the idea is Is in a normal buffer overflow, right? We usually do our knobs plus our shell code plus the address of the buffer that we want to jump to So we still want to use knobs because they're usually always a good idea, right? If you can get away with using it you want to use some knobs so that you have a little bit of leeway Our shell code Then we're going to do the address of the shell code and then we want Then we're going to have that lowest byte of the frame point, right of the say So let's see how we can put this all together, right? So this is the lowest Byte of evp right here So what we're going to do is we want this buff we want this saved evp to point here Right into the shell code Well, we want to point here So that that way when main returns it's going to move the stack pointer down here. It's going to do pop E pop evp to pop whatever garbage is here into evp And then it's going to do ret to the address of the shell code which should hopefully go down here Does that make sense? so you can so another way to think about it is We essentially want to create a fake function frame for main Right, so if we consider whoops if we consider here right here if we consider this main's base pointer Let's say we're just We're given Godlike powers and we can just change main's base pointer to point to here right before it returns Right, then what main's going to do is it's going to move the stack pointer down here first move evp into esp Move the stack pointer down here pop evp So this shell code whatever it is is going to be put into evp the stack moves up to here And then it's going to return into the address of the shell code So our address of our shell code is down here and it's going to start executing In our original program. Can we control the whole base pointer? So let's look at the program. That's a good question So can we control all of evp save evp here? Sorry, it's a little small Right, so because of this the way this loop is written Right on the very last iteration i is going to be equal to 256 And we're going to say buffer bracket 256 is equal to whatever we pass in from sm Okay But we can't access buffer 250 Or no 256. Yeah, we can't access buffer bracket 257 which would be the next byte or 258 or 259 Yeah, if we could we could use exactly these same techniques Just You know think about like if we can do it with one byte we can do it with all the bytes Mm-hmm. Yeah. Yeah, I mean Well, it'd be a little bit. Yeah, it's a little bit. This is a mistake that you're like Very likely to see right it's not likely that somebody's going to say less than You know 258 or whatever no plus fours 260 Yeah, unless they're specifically doing it for back if I was gonna do it back door I do it like this right because this is like a one character bug here this equal sign Right Trying to think I think it's defined Either by the compiler based on the architecture you're compiling on I think there's a c header file that defines the size of all the built-ins Because you can yes you can run a c program You can compile a c program on different architectures that have different sizes of characters integers Whatever, right? That's the same thing with 64 bit is 64 bit integers And other data types. So you definitely can do it I don't know if you can do it on a I don't know how to do it so that it would work on a non System look like that. I'm sure you could do it But the code wouldn't be able to interact, right? You can't run the code that thinks characters are eight bits with code that was written thinking characters are four bits or four bytes What do you mean a standard? Well, these aren't I mean these are characters, but they're It's more about the size. I mean we call them chars, but the important thing is that they're one byte Well, that's the Aspies only Only seven bits. So you only actually need seven bits for Aspie and they probably use eight because of byte boundaries, right? Yeah, but this is historical stuff, right? So, you know, they called it a car, but really the only thing that matters is the size of it, right? so you can think of a system that had native utf 8 or Yeah, utf maybe a better example of 16 where every character is 16 Bits so two bytes so every character would then be two bytes But they think it's confusing with utf 8 because characters don't map exactly the bytes. So you want to talk about bytes instead of characters That's great So now we completely control The function frame of main Right, which also gets tricky if main accesses any of its arguments or local variables Right, it's going to use our new base pointer. So we better make sure that whatever those offsets are There's things in there that are not going to break things That's actually what can make this very tricky, but also very powerful Yeah, so the problem the key problem is we're influencing. We're able to arbitrarily change main space pointer Well, not arbitrarily in this case. We can only change one byte, but you can think we can arbitrarily control it Not relatively that's part of the tricky part. Yeah, so you can't um Well Okay, you can't control necessarily where your shellcode where this buffer is on this stack, right this buffer The relative offset between this buffer and save dvp is always going to be fixed right Where your shellcode is could be a different thing you could put your shellcode in an environment variable In which case it's going to be above you can put your shellcode in one of the other argv parameters um You can even put it elsewhere on the stack if there are other functions that got called um But you need to get that address of that shellcode onto this Onto someplace where you're going to overflow and make the base pointer point Yes, yes, that's true. I mean, how do you do it? You can do it while controlling eip, right? So the same instruction pointer You have access to the fold you can let's see You could possibly do it with one byte of eip depending It gets tricky It makes it easier, but this I'm going to show that because so off by one is going to be something that is Incredibly common and then we can see how easily this can become Incredibly simple mistake can become an exploitable vulnerability if you can control more your job as an attacker becomes a lot easier Then if you didn't have that we want Yes, we want eip to point actually four bytes below the address of the shellcode We want save evp to point here So that way when it does a pop evp It's going to move up here and then the ret is going to jump to whatever's above that Yeah, so could you make this easier for yourself by Do knops shellcode and then a bunch of addresses of shellcode so that your base pointer only needs to get somewhere in there Yes, we definitely do that But we need to first find this address this buffer, right? We need this address of the buffer Which makes sense, right? Just like when we do a stack overflow, we need the address of our shellcode We need to figure that out so we can jump to that code right So you can actually brute force this Just like with knops lids, I mean you can try a bunch of stuff and eventually it'll hopefully get it right You can also Try to find out use a debugger try to find out where the stack pointer is and try to find out values What do you have to keep in mind when you're doing this with the debugger? Yes, the debugger adds environment variables, so it's going to shift things right and you can still It gives you a pretty good target to hit for right and you can kind of adjust So you can look at the function you can see Uh, the function is here. We can set a breakpoint at this function and then we can Run it and then see in this case The stack pointer is at bfffc 60, right? So we can actually find the address of our buffer should be so the stack pointer right move down to make enough room for the variables So right at the stack pointer is i Right and then four above that is going to be should be the address of buffer Right, so we'll use uh bfffc 64 But now we want to know what's the address of the address of shellcode Why do we need to know this? Let's go back to our diagram Yeah, we need to know how to change evp to point here right So we So we need to actually determine what that last four bytes are Right and we're trying to be precise here, but how many tries are going to take you to try all possible values for one byte? 256 for those that brute force A sign of two how many tries do you have to try? A couple billion This 250 16 a lot more feasible Did we even do that by hand if you want to do so? But let's talk about how you would try to do this if you're trying to be very precise, right? So we're We need to determine those last Address of the shellcode right because we want to determine where we need to change Let's think about what we already know based on this example What do we know about ebp? from this example Is it going to be The ebp that we want it to be the address of the address of shellcode Do we know anything about it from this diagram? Yeah, so a it's right below it. So it's going to be what greater than less than? less than Less than greater than higher lower, right? So it's going to be less it's going to be Something that's going to be less than us, right? And it's just one of those things you can use the self-check. It's calculating this, right? Okay, so we want to first so we have the stack pointer, right? We have the address of buffer Then we want to we add 256 bytes To get to the very end of the buffer right That's pointing at the address of the address of shellcode But we want to subtract four bytes because we want to move down and get to this point here Right, we want to be four below where the shell address of the shellcode is because that's where we want to eventually execute But we first are always going to do a pop and then a wrap So we can actually just calculate this we can say, okay, it's probably going to be here So it's going to be this plus 256 up from the stack pointer Uh actually from 250 260 up right because it's the stack pointer plus this plus four minus four plus uh 256 So the nice thing is since we do know that we're going to be very close to evp to the saved evp Right, we know we can actually probably do this with just the one byte Right because we know save evp is going to point to somewhere up here Right somewhere above us on the stack No, hopefully it's not if it's too big then we maybe can't do it But in this case we know it'll probably be very close, right? So we probably know these first three bytes are going to be in the same ballpark. Yeah Yes, it would point it would point Uh essentially here. Yeah It'll be I guess on this example There'll be what four up for eip then four up for sm Which is what we said and then that should be where evp is so four and four eight. So it'll be eight bytes up Yeah, so this depends obviously right on the Size of main right because main is going to have local variables So what's the size of the local variables in main? Are they really large? Are they small? Okay Okay, so now we need to figure out where this is so we want Evp right that save evp to be the address of the after the shell code minus four Right you're going to take us down for Because the stack is going to be incremented when we do pop evp So from our example our calculation is 57 so we can calculate that to be 57 Right because we want to put the address of the shell code in there. So we need So this So right so this we just calculated what byte to overwrite So now we calculated exactly right here what this address is remember But we need to put something in for the address of shell code that we're going to jump to right So we're saying it's going to be you know 16 bytes down or whatever Whatever we calculate is going to be within that range right so is You know that's knowable right because we're passing in this All this value here, right So we know What we think the save evp is going to be and then so they address the shell code should be just 16 bytes below that And so in our case we'll use this example so Now so what we're going to do what the code is hopefully going to look like right needs to look like this Where we have knobs We have our shell code our shell code starts our shell code ends And then right above that we have the address of the shell code, right? This is so in a normal buffer overflow, right? This is what we would try to overflow evp with So that evp would start the save evp would start executing into our shell code Right, but we can't actually do that, but if we can change this Saved instruction save base pointer right So that bff fd 5c is here Now When main returns it's going to set the stack pointer here to be bff fd 5c It's going to pop evp and pop this last four bytes of the shell code into the base pointer And then it's going to do ret Bip Uh, sorry return, which is going to jump to this code which is going to jump down here and start executing this But you are having the assumption that nothing else is relating in this 5c I'm The assumption is that exactly at this address bff fd 5c or I guess the save evp Change the last byte to 5c is going to be this specific byte in my buffer If it's any other byte this whole thing is not going to work Right because we're going to put a different value in base pointer And then the base pointer of main is going to point somewhere completely different Cool so if we see this if we go back to our example now that we've overflowed the save base pointer Right now we move base pointer into stack pointer Right remember this is functions epilogue So now this instruction pointer just like the floor is going to point up to here We're going to pop evp Which is going to cause the stack pointer to move up one And the base pointer to hopefully point to right here, right? This this is our goal condition We want this to happen But no right here. We still have you know, this is the important thing right we have taking control of this function Right it's still when it calls return It's going to jump back into main by using the save instruct eip, which we haven't touched at all on the stack So it's going to do that. It's going to jump back into main now, right Function returns evp should point to the address of the address of shellcode minus four So that when main returns it's going to Set esp equal to where the base pointer is it's going to pop evp Which is going to increase the stack pointer up one and then when it does the ret it's then going to jump into our shellcode So this is the goal. So now we're in mains epilogue, right? So this is the key same steps different function So now we move the base pointer to the stack pointer. So usually when we do this right the stack pointer goes up Right because it's freeing memory But since we've corrupted and controlled the base pointer the stack pointer is actually going to move down Right the stack pointer is going to point right here And then we're going to do pop evp Which is then going to move this Shellcode into evp, which means evp is going to point to garbage. Does that crash our system? Why? Yeah, we haven't dereferenced it, right? We don't care about it. We haven't used it right now Exactly Now we do a ret and then where are we going to where's the program counter going to point to? The address of the shellcode, right? Which should be somewhere in here Well, put a little bit down, right and then it's going to start executing our shellcode And maybe it's hard to tell in this diagram, right? But we can see that we've actually So by doing this right when main returns now essentially you could see mains frame Main's frame is no longer up here as far as main is concerned, right? Main's frame is actually here Right because we've controlled the base pointer and we've essentially tricked main into thinking that its frame is farther down the stack Right at an arbitrary place. We can control and since we've saved the same instruction pointer is um Inside the frame, right? The frame defines where the save instruction pointer is If we control that frame is we can control where that saved where the code goes and executes So more sophisticated attack than standard buffer overflows, right? We have to be a bit more precise, but um I think it's really cool. Yeah, absolutely. Yes. Well, it needs to be somewhere in the processes memory. Yes Make it easier for ourselves You don't ever need a knob It's just to make things easier for yourself Because um, so you can think that with the knob that means this address of shellcode must be exactly byte precise right And the same thing The way we have it now, right by overriding this byte. We have got to Having the save base pointer point here. Otherwise everything fails right, but We could actually add a couple of address of shell codes here to then make it so that we only have to get anywhere in here Right, that would be helpful. Um So yeah, that would be one thing to do, especially in this example is put your shell code in the environment somewhere Right, which is where you know what you've been doing with the other Hopefully some other stuff, right? So you kind of know that it's going to be up here somewhere Then in the buffer have the buffer be the address of that shell code everywhere Right, then this should be very easy and you just need to guess the address of the shell code cool Okay, so how do we fix this? Use a different language. What language are you going to use that doesn't have c at the bottom? Ah c plus plus is it what c plus plus? It's just the same thing. You could have the same example and c plus plus A range base for loop. Does it work on arrays like like buffers like this? But how does it know the size of this? Uh for instance Yeah, how does it know the size of sm in this case, right? It's just a pointer Ah man, we covered a lot Yeah, right, so Okay, c plus plus was not a big example. I was looking for It's a java java, right would be an example, but still what's the java jvm written in? See right doing the same stuff under the hood Okay, where are we? Okay, what else? Is it going to cause a security problem though? Is are you going to allow you to control the x what happened if you access an element outside the bounds of the And you get an exception right in the program term where in this case the program doesn't terminate just overwrite the memory You can't Overwrite arbitrary memory in a java program because it's checking the right bounds you mean arbitrary Oh, yeah, yeah, that would be well that would give you a little bit that would help definitely off by one You could even just add some padding right between the local variables and the stack That way you're protected from off by ones maybe add a bit more so it's off by one that's Depending on the size of your off by one, but yeah, that's kind of only your Yeah, it's exactly. Okay. So you've got to thoroughly check loops Right, the problem is so you can control that loop iteration count right in this case It was hard coded it was hard coded incorrectly Right, but if we control that loop cap, we can get it to overwrite. So yeah as we saw we can do crashes We can cause the program to We can cause arbitrary code execution all kinds of bad stuff All right, so let's stop here I will not be here on monday sigh stand up raise your hand Sai is going to be proctoring and probably some other people as well since there's a lot of people in this class, so Uh, good luck


18 soldiers from across North Carolina and the rest of the country conducted a Special Forces Readiness Evaluation, or SFRE, from September 13th through the 15th. These soldiers are among the best in their units and all have ambitions of completing the U.S. Army's Special Forces Assessment and Selection and subsequent qualification course to ultimately join the Special Forces Regiment. Bravo Company First Battalion 20th Special Forces Group conducts SFREs to prepare and evaluate potential candidates. There were many different assessments beginning with a PT test and a pull-up event. Soldiers also carried 45-pound rucksacks in a timed event and completed a swimming evaluation. Sergeant First Class Fisher and the evaluation team are looking for candidates who can perform to the highest standards. We have to look for somebody that is able to think under duress, that's able to perform under stress, that's able to work individually as well as part of a team. The Special Forces are the subject matter experts in unconventional warfare, meaning they work with populations around the world to train other militaries and conduct operations to preserve the freedoms of the citizens in those countries. The demands of this elite organization are both physical and mental. Soldiers selected at the end of the SFRE will be recommended to attend Special Forces Assessment and Selection at Fort Bragg. The others will return to their units. For the 382nd Public Affairs Detachment, North Carolina National Guard, I'm Army Sergeant Adrienne Brooks.