 speakers, Joseph and Ilya, who will be talking about how bootloaders are broken and how to sort of look into them. Please give them a warm round of applause. Hello. Does this sound okay? Okay. Cool. Yeah. So, welcome to Boot to Root, auditing bootloaders by example. I'm Joseph Tartaro. I hack things for IOActive, and this is my second time at Congress, so I'm really excited to be back here. Hi. I'm Ilya. This is my 18th or 19th time at Congress. Happy to be back here, too. I spoke here, I think, seven or eight times before, and I'm very excited to speak here together with Joe. We've been working together on bootloaders last year in change, and this is minus the NDA coverage stop. This is some of the things we've observed and seen, so I'm very excited to do this. Yeah. So, the expected audience for this talk would be embedded systems engineers, security people who are interested in embedded systems, and just curious security people. Just a caveat, we're going to be quickly going through about, like, 70 slides or so, and a lot of it's just, like, examples of C source code, so if you did not realize you were signing up for an hour of that, feel free to walk out. We're not going to be offended. And then another caveat would be this isn't really trying to flex and show, look at all the bugs we found. The purpose of this was to kind of show people, hey, if you have not looked at bootloaders before, this is our recommended, you know, areas of attack surface that are interesting. This is probably where you should get started, and in some examples of nobody's really looking at them. So, quickly we're going to talk about what we're going to be talking about. What are bootloaders? Why? What are they? What are they? What are they? What are they? What are they? What are they? So, a wide interpretation of bootloader. So, just to be clear, that's an area that's in your security chain, and you haven't had experience with these, or you have a boot chain, you can kind of take it from an operating standpoint of user land calling into kernel space. You'll have a lot of people calling into this stuff, and that's kind of what you're looking for, is pivots and when they're processing, you know, those data for security. It's a key component of your security process, and it's very obvious that a lot of devices are burning, limiting attack surface. And what we mean by that is a lot of the devices we've looked at over the last year or so are flying devices that have, like, full network stacks, even though they don't really make sense why they're not limiting all that attack surface. There's also a huge understanding that there's no bad people who are attacking, that there's a black yaw, that there's a story behind the presentation, that there's a story behind the presentation. We were going to the baseball game, I was trying to get to the baseball, and we were talking about Ibu to get a phone, and then I went out on GitHub, Ibu. And we found some bugs and we thought, maybe it's worth doing this thing. There was a previous presentation that was about the issue of the Bethesda loaders, and we were going to touch on that a little bit. We didn't look at it for the first time. There are a number of people who have inspired us. And we recommend it if you enjoy it. If you like it, you can look at these people if they released some articles and published articles. And where are the loaders? They are almost everywhere, on servers, on consoles, on TV, on tablets, on phones. Almost everywhere. Obviously, the security of the loaders is very important. So, with that said, we basically started looking at open source bootloaders. For example, it's Uboot, Corboot, Grubb, Seabass, Cafe, IPXE, Tineco. We're just looking at what's on GitHub, what we've looked at in your real world scenario of course, all these devices, they're going to be heavily modified. They're going to be custom drivers and things like that. So, again, we're not here to discuss the possibility of how we can easily store bugs in these things. We're here to show people, developers, what they should think about and what they should look at. So, let's look at Uboot. Uboot is a terribly, very widespread loader. It's a very good customized config. There's a lot of variable loaders, Shell, and there's even some problems for shell injection and so on. An interesting feature of this Uboot is the stack of the network stack, the file system, and they're also going to load from the next level different images, like Ethernet, hard disk and so on. And they're going to use the built-in Uboot. Uboot is designed for modern operating systems. They don't support BIOS. It's used in Chromebooks and pretty interesting things that happen from Google. And they don't use it to load other things, they just implement their own functions and keep SNM grab. Obviously, all of you know these loaders, and they support just a ton of files. The main problem is probably the multi-boot, and there are interesting things that are used here. So, it's kind of like your Uboot, the verset group grab, and then CBIOS, this is a standard BIOS for QM and QVM, so you can see that the old BIOS calls, and it also supports TPM, which is kind of interesting, and it also has a module for UFE, and then CAFE, and then this Broadcom, it's used in various routers, TV's, and obviously, all the main bugs will be connected to the stack, and you can work with other stuff. IPX is an open source loader for IPX, and it's signed by UFE, TANACOR, there's really no introduction needed here, there's a huge number of people who have been doing everything to this thing for the last 15 years, and the most stocked loader that we have, and there's a lot of... there's a lot of limitations that were built based on TANACOR, for example, Qualcomm, XBL, and so on, you have the main base of TANACOR and all the rest is built based on it. And then related to bootloaders, we have things related to bootloaders, and as I said earlier, there's two worlds, safe and less safe, and you probably want to look in the safe world, and not safe, you have some secrets and so on, and you can put the bootloader on a variable that will be used for the next load, for example. You can take a picture of this because there's a certain function here, how to assemble it, how to look at it, and you can delay it and start programming for the bootloader. Let's quickly look at how the secure boot works, how the chain of trust works, how the boot drum works, how the loaders are at different levels, sometimes there's TPM, sometimes there's HostOS, depending on the host and operating system, and different load configurations. The boot drum itself is probably the first level that you've probably seen, it's the root, it's very important, because it can't be lost, it can't be found, if it's found at some extent, and it's very early in the stage of loading, so it's very small, it makes very small initialization, memory, low-level things, sometimes things like the fastboot, like maybe the USB stack, USB stack, which is a clear goal of different types of attack, and then it's transferred to the next level. And then the loaders start at the next level, and there are things like Wi-Fi stacks, SMM handlers, encirclements, some hardware environments are in some encircles of the hardware, there's Armastron, HP, there's Hypervisor, and the bootloader will send it further. And in the end, the operating system is loaded, it's checked, and in the end, it's running, and we're having fun. Everything that we were looking at was with an open-source code, and everything is pretty privileged, there's no userland, there's no food, there's no isolation, there's some, for example, some propryter loaders, they used to limit the privilege, but what we looked at did not have anything like that, but maybe we'll see this list of attack surfaces that people should focus on, and it will be interesting, it's in VRAM, file system, Stag, different tires, like USB, SPI, SMM, DMA, and other stuff for the hardware. Usually, developers are engineers for... Usually, if they use USB, we have to check it, but we don't. So, in VRAM, there are some variables that can be configured from runtime for the next load. So, the user user data is used, there are interesting functions in every loader, which you can look at, environment get, and you can see how they work, how they levelize some data, and so on. For example, there will be a boot, for example, NV get from boot BI, and as you can see, I just copy it without checking the size. We thought why not use this activity, and we tried, and we sent some package, just like this, boot P, and we sent some raw packages, and it wasn't very realistic but it was very simple and interesting, and we decided to look at something else, and quickly set up an environment, and we'll get into a little bit of an exploration. As you see, we're using hostname, and the same pattern as we see, we copy it without checking the length, we use stercup, it's copied from multiple times in different parts. The code is not very cool, to be honest. We thought that maybe we could find other bugs, we'll take a variable, and some part of this variable, and without checking the length, we continue to use it as a code. Yes, for example, we can look at an example. The scenario will be you have a device with an environment, and you'll see a variable which is very long, and that's the address. You just file a system of JFF, and it will be executed. So, hey, it's just a shell code. Obviously, if you've never looked at this stuff, you should start poking at it because it's not that cool. It's pretty fun. Okay, let's take a look. These were the attacks on NVRAM which are the most fun to play with them. But in terms of in terms of in terms of attacks, it's not very interesting. String copies, copying from some lines, it's not very fun. There's not only NVRAM, but there's also other playability in this place. Another interesting thing is the file system, because you need to find where to load it, how to manage it, and how to do it. Often, the file system doesn't check the integration check, and so, sometimes the file system would be a fat file system if, you know, loading a USB drive and, for storage, then the device that we're loading, it's going to be fat, or it may use X2 or X2, or some other file system, but it's a good attack on the surface of the attack. There's also files that you might not be able to verify, so you're interested in that, and if you're eager to work with any product, then it's a good idea to recommend how to start phasing these files. It will be interesting. In a number of bootloaders, we'll cover X2, we'll discuss X2 in Graby. I think the examples of where there could be bugs, but those two we'll cover. So this is Grub, and this is Grub X2, and Grub X2. This is the sim link code, so it puts the file, and it says, okay, how do I parse the sim link, and it says, hi, I'm sim link, and I'm so long, I'll allocate that with size, and I'll analyze a certain number of bytes. So this is a classical implementation of Integer. It's a very perfect example of the index of the element of the zero-size buffer, and obviously that's going to cause every corruption, and it will cause damage to the memory. So this particular read function, actually, if it stops reading, it stops reading, so it only reads, let's say, a thousand bytes, or a hundred bytes, even if it causes memory corruption. So this is a bitmap splash screen parser, and I don't know the ending about bitmap parser, but this is an example of a bug in bitmap parsing for splash in the map. If you have a 4-bit BMP, then you have a certain palette that when you have a 4-bit BMP, then you have a palette of 16 numbers, but you can send more colors, and this will be a problem. The other aspect is TCP-IP, and let's see what we've looked at locally, and what we can do with the remote. In the modern world, TCP-IP and some certain services that you use, connect to most likely DHCP, DNS, iSCSI, NFS, or IPsec, HTTP, HTTPS, ITFTP. Of course, there's a code for parsing TCP-IP. You need to do good because you can't do anything. If you take a step back and say, let's take a step back and see what is parsing to LV. There's reading outside the border and a lot of things like that. If you look at the protocol here, DNS, DHCP, you get some attacks on the web, such as a cat's poison, or a rent theft, predictable IDs, poisoning, ceiling attacks, and so on. There's also what we'd like to look at is bugging memory damage. If something goes wrong in parsing, you can do bugging on memory damage. Also, for example, when hard bleed leaks about some kind of information, some kind of thing is responsible for something. And sometimes, I can show you are looking for these kind of bugs in a... I would highly recommend fuzzing them. I highly recommend fuzzing them for network stacks. For example, you can use isic, which is pretty old, but pretty useful for that. So with that said, for example, for example, Ubud. For example, it's a DNS code for Ubud. There's a TID, this is a DNS ID. There's a static DNS ID of one. And because Ubud is... Ubud's environment is pretty simple, and it's always the same. It's a Coffee, it's a parcer of DCTP, and there's a buffer for junk, for any garbage. And there's a function that gets the value of this thing. So it reads and gets the stack damage. If you look at in the TTP part, it's also a very similar thing. So he copies the entire buffer into this sweetener, to 1,500 bytes in this 512-size massive. And again, we get some memory memory, because it has such a beautiful code. So it's a pretty cool code. And this has a really cute sort of a nice thing. It's IP-free, it's no problem. Since they're receiving, it sends a ping, and it's easy to receive it. And it waits until it finds the right one. And it waits for a packet when it finds the right one. And because it has a loop, it has a cycle, it has a timeout. But it also timed out at the exact same time. It frees that packet twice. And if two things happen at the same time, timeout and getting a packet, then we get memory damage. So the IP-handling-coffee, and if anybody has an IP which they have, do you know it has an IP? I have two different lengths. But coffee validates either the IP-header length or the total length. So these are missing with the IP-header. So that was sort of a quick overview of TCP and TCP-related bugs. So let's say we've got that covered, and let's say, you know, okay, what's the next thing? What more should we do now? I think we've got 11. Yeah, we have 8211, that's our Wi-Fi stack. Don't have anything to do with it at all. It's one of those kinds of things. We didn't get to having this feature yet, but we will at some point. And obviously we're not going to use this function, but at some point we're going to use this function. Well, I think I did want to mention that. If you look at it, if you look at it on Wi-Fi, depending on the size you haven't printed, depending on the type of radio you're using, in which case the stack is kind of covered because what I hope it is where the radio does a bunch of validation. If you use an adapter, what kind of adapter do you use for Wi-Fi? Because this adapter can do a lot of things that are inside of it. And from the point of view, if you look at the attacker in the bootloader, then you're most likely interested in the inside of the bootloader. You know, anytime you do any kind of Wi-Fi stop, the first thing you do is you, right? That's right. So just think about it. You're most likely looking for SSID from the Internet. So that is 32 plus one. And it has this where it sort of goes over IE that it gets. And then when it comes to IE, it says OK, we'll take this IE, and we'll do IE length, and IE length is 25, and it says SSID, IE into the SSID length. And it copies this buffer from Beacon and causes damage to the memory when you get the Beacon package, the frame. The next one, if you're thinking networking would be Bluetooth, we're just looking at the support of Bluetooth. Unfortunately, we can't talk about those bugs because we have politics of non-disclosure at the moment. We can't give you examples of bugs in Bluetooth in bootloaders, but we can look at what we can understand, what it might be, what we think might be bugs in this bootloader. Usually for HID device, right? This is our keyboard mouse. This is our keyboard mouse. I didn't generalize this, I'm looking for any kind of parsing bugs and you would probably look at some bugs in parsing. There's three recurring teams that we saw when we looked at about three often-repeating schablon problems that can happen. And this is usually related to usually connected to some very long frames and frames can be up to about 65,000 bytes. And frames can be up to 65 kilobytes. And when you can fill up to the end, I don't know if you create very, very, very short frames. You know, less than what something is expecting. That tends to blow up. Also, if you send a frame that is less than expected, and every fragment can be X amount of bytes, but the whole thing can be up to 65,000 bytes a byte. 65,000 number of bytes. So if you start playing around with the fragmentation, do you use that simple map again? I wish I could have shown an actual bug. I wasn't able to find any open source bootloader, but this is what USB does. This is that prime-tack surface in bootloaders. Obviously, it has shown up in a versace. There are some devices that, at least up till recently, I think was sort of under-ordered, or sort of people didn't quite care about it. So sometimes that's the thing. Every time I listen to what they say about USB bootloader, obviously, the first thing that comes to mind is USB bootloader and January. I think I use it for storage or, you know, things like, you know, dongles, or something like that. So basically, if you start looking at how USB works at a slightly lower level, you can see how USB is pretty low-level. It's more packet-based. So what's interesting, when a device is closed, the device is asked for, and these descriptors say certain things about your device. Each device has its own descriptor, and it's very often realized incorrectly, because this device sends descriptors to any of the things that are happening, and what class you are, and what functionality you expose, and all these kinds of things. So generally, we often see some sort of overflow or some sort of double hatches or some sort of double hatches that are pre-added to the headers of these packages. The question is, is it possible to read the protocol without reading it and just get the header? If you re-write the initial length of the header, then the first time you get a header with the correct length and the second time with the wrong length, if it wasn't validated, it could have been a bad thing. No one is expecting this. This is an example of a grab, where it goes and gets a descriptor, and the descriptor says, here are my configurations, go into configuration, and go into all these configurations. And there is a certain array of these configurations that are supposed to go through. It just always assumes that the config count is always connected to the array. So it's always connected to the array, and I know your arrays are two bytes, they're two elements, but I'm going to give you 64 configurations. It's always assumed that there is a certain size of this array. And what if I send it much bigger, if it's bigger than, for example, if it's between two? And in the Taiana Core there was a similar bug, and the descriptor uses the length, and the descriptor length is a U and 8, so it can set up to 25 bytes, and so that would have smashed and also cause memory damage, because the buffer is pretty small. And the idea is that it's not necessarily checking the borders, you can just make the buffer bigger, because the descriptor length is just 8, that is, 8 bytes. This is an example of CBIOS, for example, a typical double fetch, and it doesn't verify the length, and because that verification is here, whoever calls this sting can no longer trust WTotalLength, because it could be... It doesn't check WTotalLength. As I said, USB to me is one of the most obvious attack options in Secureboot, and there were a lot of problems with the useability of them, connected to Tegra, or something like that, because they're not compatible by the USB port, that basically, you know, you give it a length that's not validated and then a memcop, and then a size that's not verified. There were also problems with the iPhone, with the CheckM8. Obviously, there's a set of certain machine that uses it as an interesting attack surface. If the chain uses these MTV-shines, ASPI, SDIO, I2C, and then this is an interesting attack, the VectorAttack, it's also very interesting if you have a TPM, because it also fits there. So this is, for example, what happens by memory. For example, CBIOS, and it goes and gets this structure and you can set it less than what you expect. And then, see, the size of the structure is less than what it actually is, less what they expect, and so that causes an integer underflow which ends up in the size of the integer, and malloc internally has the underflow, so that really big size then becomes a very small size, and memory copying takes place and so that's how memory is reflected. And this is the malloc internals of CBIOS, which I don't have, which I don't have inside malloc. I don't want to go into details because this is a training for the audience where there's a bug with an integer underflow. So another service, attack service that is interesting, but often overlooked on devices is system management mode. And the last decade, last five years, there were a lot of interesting research on SMM, and it was a bad house game for years, you know. Somebody breaks something and it was a bad house game for years, you know. Somebody breaks something and then Ufi fixes it and then somebody breaks it again and then Ufi fixes it and so on and so forth. And occasionally people find bugs, but by the launch, you can hear a little amount of SMM handling. Third party stuff that still breaks occasionally will be damaged. Now, what we're doing is X86, but you're going to screw it up and it will take you, and you're going to screw it up and it will take you another 15 years to get it right. But I guess if you were to try the first time, this is what Coreboot does and they said we should range check it. We have an input and we're going to check the range on the diposon. And they're going to check the diposon. Okay. So, now, I talked about a bunch of buses and the thing to me that sort of separates that from all things, because DMA has been around for as long as DMA has been around. The idea is that there's no limit to trust and so what we have is an AMMU. If there is such a thing, DMA can be stopped, controlled and you can implement the limit of trust with an AMMU. Not that many people are doing this, right? You should. Because it's not so simple. There are different AMMU on different architecture. It's like Intel VTD, AMD, ARM, SMMU and all of them. If you use one of these, DMA is not the end of the world. What if you have an attack on the AMMU itself? What if you use a driver that was written before using these limits before AMMU, written without taking into account these limits? You should look at all the drivers that were written and see if everything is written correctly and what to do. For example, you did it all correctly, but because you have these limits of trust, you can't just open two devices, right? You should clean up your memory before you use it. Well, now you still have a dependency on the AMMU because you are assuming the AMMU is perfect when it probably isn't, right? You suggest that the AMMU is ideal, although there may also be certain bug attacks. My plans in the future are to look at the AMMU and find bugs there. I understand that there will be attacks on the external channels and so on. So, this is what this is going to be today, in the final where that's what we're trying to do. If you look at the spec from Ufie to the next stage, Ufie basically boots up and very early configures the AMMU and makes sure that the device is loaded and initializes the AMMU and then it controls the operational system. Well, I don't know if the next guy would undo all the AMMU program it does but every time it does it doesn't know what's going to be next, so it uses the AMMU and then does the reverse operation to fix this for new devices. This is for the future but it takes a while because you're going to get the time because you're going to get some kind of specification. Yeah, now this is where hand back over to Joe. I think it's a pretty good idea but we thought it would be a nice thing to mention to people. Well, it would be very naive not to mention our presentation. It's glitching, with glitching you have like fault injection and a lot of times people go after things like the signature verification stuff and very often people look at the signature verification for example fail overflow for PS4 on Cisco. Very interesting blog post that you should go to debug mode or something and it would say that's not enabled, infinite loop and then there's glitch out of it and it initializes debug mode and then it goes into the debug mode with timing discrepancies for example, there's different timing different time time time time energy problem with the processor and so on. There's also chipsack it's going to be a very complicated attack which opens a very complicated attack which produces extraction of different things from chips but it's not our presentation that's about this is kind of presently it's still expensive equipment now not so many people have so many expensive things to produce such attacks but pretty soon probably soon in the garage ordinary hackers can do this when all this equipment becomes more accessible and so it's not worth worrying about that I'm not going to be worried about these difficult attacks and also noticing the integrity of the code it's very difficult to do it right because it's a very weak cryptography weak algorithm problems with blocks when there's a list when you have a signed grub there's Kaspersky I published a bug in a signed grub you can load this thing and you can put them into your boot and in this way you can list it in the black list as a loader to but the block list can not always be updated and it can also be a problem and sometimes some execution files are not checked the conclusions are just the top of iceberg and a lot of work we really we really it was as soon as we decided we have an hour, let's see what's in there we found a bug we looked just in the list and until we found one bug we stopped we were surprised how bad the quality of the code is in the loader and if you want to look at the proprietary loader you need to sign some NDA it's not going to happen and if you want to do resource engineering or look at some problems you need to solve and some tips that we can give to minimize the image and turn off the functions that you don't need, for example, the network, the USB and the final system and the environment which is insane is like these little embedded devices that are running Linux and they have more drivers than our desktop at home and they use Linux and they use much more things than our usual computer about some protection against such things as you saw from the example before this morning, just really quick in the morning and that's it there's no SLR there's no support and the whole thing is about the code and Taiana Korova is pretty ahead of everyone and it's pretty cool what's going on and it's a call to action a little call to action if you haven't seen this before and you were not sure then just take it and start doing it and I'll have a workshop that you can watch and we can help you and we can do a little exploit or something like that and it's clear that there's no code for all of these things and it has to happen and we really looked at this code we sometimes just took some device to see if it breaks or not that's all we have thank you thank you now we have about 10 minutes of questions and we'll start right after the internet thank you, has the grub issue been fixed yet? was there a problem with the grub? I don't think it's been fixed yet and I don't think it was already fixed this was from whatever the official grub repository was it was from some official if you have a question in the room please line up at the microphone if you have any questions then turn to the microphone you said you wanted to build a more secure laptop so that everything is compiled inside and that there are no modules and what if someone tries to break or get into maybe DMA access because you somehow access the network device that has some special firmware to optimize the traffic or something and that this thing if there is some kind of an adapter that goes through it that's what you're talking about that's what you're talking about that's what you're talking about that's what you're talking about and that you're going to have and then just put without drivers static core that just loads all of this in the flash there are some problems that you can fix that can be recorded in memory through DMA because they have access yes, we had a problem we always used DMA and it was always a big problem so now we use AMMU it depends on if you can scan AMMU or not you can protect your device with AMMU I think that answers your question it's all you can do about these attacks if you want to make a hard laptop that you use in hostel environment right, I mean I think it's a really useful tool that you can use because there will be bugs there too but I think that's the best I can come up with yeah I mean you minimize the attacks when you have it as minimal as possible then you just kind of You don't want to do anything there. Oh, you mean the corbots on the host? Yeah, I mean, let's say you have a corbot on the Linux... For example, you have a Linux and a corbot. And you may be taken... And you may be taken after the talk. Okay, after the talk. What is your favorite... What is your favorite... ...signal angel that you use by reverse engineering the bootloaders? We just looked at a source code. Yeah, we didn't do reverse engineering. We just looked at a source code. I mean, for this particular case... In this particular case, except for the... ...we didn't have much need for it. I mean, we didn't have to do some reverse engineering. I guess a little bit of GDB engineering. Maybe we needed GDB for the bootloaders. We played a little bit with Hydra. It looked promising. We just needed a lot of eyes. GDB is pretty bad, but... ...in general, I... I have two questions. What is your opinion on the... ...the... ...the... ...the zone. I worked with it. And I was just shocked. How complicated this thing is. Should we also question the... ...the boot ROMs? What... ...the boot ROMs are often very bad. Maybe we need to... ...to strengthen some other things. It's like you're working on this? Yeah, it looks like you're doing this. So... Well, your first question was what again? Do you think about the... ...the... ...the first question was what you think about the... ...the zone. I... ...I touched upon it and a few engagements. Like you, I just tried something. I can't talk about it, because... ...it's... ...it's... ...NDA. Yeah, and there are some things that cause... ...some suspicions, problems. Yeah, the problem is that you can't just... ...start a bug, but you need... ...to try to minimize it. So you can... ...you can... ...in your boot ROM you can... ...you can... ...maybe you have some function that... ...you can add to your boot ROM. But you can't fix that. But you can minimize... ...the amount of stuff in the boot ROM that's coming in. But you can't minimize all of it. I mean, there's gonna be some of it. I mean, there's gonna be some of it. I mean, there's gonna be some of it. I mean, there's gonna be some of it. But I don't know if any... ...I just wanna say this kind of touches on... ...when we said people underestimating... ...reverse engineering... ...reversed engineering. And, you know, when somebody finds a way... ...to dump a boot ROM, they start looking at it... ...then they just see, you know... ...but you just need to stack it up... ...and that's what you do. And I don't know where... ...the first thought is... ...I would say it would make more sense... ...to do more... ...open. And I would say that.... ...it would make more sense to do more... ...open. And I would say that... ...it would make more sense to do more... ...open. But in forma... ...we didn't see a way to... ...seeター. You need more eyeballs... ...to actualize...那麼, лучше 얼마나 speculation, ...but, you need more eyeballs... ...to actualize. I think there will be some eyes that might be interested in this process. We have another question from the Internet. Yes, are you okay? Are you good? And maybe even free bootloaders? Do you know any good bootloader phasers? No, not at all. I actually don't. I've shown some places. If you're doing any kind of file-based stuff and you can want to look at some of these things with a file-based system, then I think you should take a look at the Wi-Fi phasers and DNS phasers and so on. Yeah, I would say the best way, in my opinion, would be to pull out the interesting things that you're saying, and the stuff you're concerned about in front of you for that. So, really interesting things for that in partings, pull that feature out and harness it up and run on a bunch of cores. Yeah, so it allows the way to go all the way to a whole separate piece of this code, just as a kind of tool-place. We're using the occurrence of such errors by using another programming language, like FTO ModSecure, things that compile time or during run time, like maybe RAST. problems. If yes, then there are some other things, other projects that are not used, I use other languages. I think we can reduce the number of bugs. If we get used to Rust, we can reduce memory damage. There are some extreme cases that can not be found. Often memory damage does not exist, but also some things that were developed at some level disappear. There is a runtime for Go, in the beginning of being researched and being worked on. I think it's very interesting, I think that we can go into, I think that we can look at it, I think that there is something there, but at the moment it seems to be very early for this. There are a number of bugs that are going to be there. There are a number of bugs that are going to be there, because of memory damage. Basically, there are bugs in iron, bugs in logic, etc. But this will definitely help us. And that's it, we have run out of time. Thank you to the speakers.