 Hello DevCon and hello IOT Village. My name is Alex J. Boran. I work as a security research director for P-Defender out of Romania. First of all, I would like to give a quick thanks to the team that made this presentation possible. They are Radu Alexander Bazaraba, Alex Lazar and Yvonne Melnychuk out of our office in Cluj. Now we're gonna dive right into it. This talk is going to be about some of the findings that we've found, I guess, in the past five years while doing vulnerability research in IOT. Now a few things about myself and about us. I think it's the third time that I've spoken at DevCon and IOT Village. I'm happy to say that I managed to speak at the last edition of DerbyCon, simply because it's such an awesome conference. We've been doing vulnerability research in IOT since 2016 and we found vulnerabilities with a very high severity, so let's say an eight plus in the CVSS score in more than 20 brands. We published 12 papers amounting to only a small fraction of our total findings and that is because we had very poor or no reply from vendors. So one of the biggest challenges that we faced in these five years was getting the vulnerabilities that we found fixed and since a lot of the things that we found had a very high severity, disclosing them without having them fixed may have resulted or could have resulted in mass exploitation. So we imagined that we found vulnerabilities that affected let's say 10 million devices and the vendor didn't reply. So one of the biggest challenges that we have is getting a hold of the vendors and getting them to reply and fix their stuff. Roughly four years ago, we started to focus a lot on IOT Cloud platforms and these are some of the topics of the IOT Cloud platforms are gonna be a hot topic in today's presentation. So far we've published about 12 papers. So the list is here on this slide, you're gonna get the slides after this, but I want to emphasize on the huge amount of papers that we didn't publish and that includes some well-known brands and mind you, the list that's on this slide is not the whole list that's in our internal repository back home. So I want to take this opportunity to emphasize once again how bad the response is for most of the vendors that build IOT. Most of them don't have security contacts and those that do have security contacts don't reply to those emails. We've even tried reaching out to them on Twitter, on LinkedIn, getting a hold of them by friends of friends. Do you know anybody that works at company X and that kind of thing. So again, I'm taking this opportunity to raise an alarm about vendors and the fact that they don't have security contacts and the implications that this has in the grand scheme of things in security worldwide I guess. So many unpatched vulnerabilities and that can still be exploited to this day. Some of the exploits that I'm going to outline into this presentation can still be used to this day in a large number of brands and vendors. So that being said, the first chapter and probably one of the coolest is reusable attack vectors and common vulnerabilities. Essentially these are vulnerabilities that affect more than one vendor. So stuff that can be used en masse and on many, many devices. One of the most common ones is hijacking the wifi password during the setup process. So essentially it's a technique that enables an attacker to steal a user's wifi password during the setup process of an IoT. So here's how it works. You get an IoT, you start configuring it. The first step usually is to connect to a small hotspot that the IoT makes. Let's call it awesome secure IoT wifi. And the mobile app tells you, okay, the IoT created this hotspot, connect to it. The next step is to then select your home wifi, enter the password of your home wifi and then there's a bunch of other 20, 30 steps about configuring additional stuff like setting a common name, maybe setting up alerts, notifications, different other types of settings. After that's finished, the mobile application starts to communicate with the device and usually crashes and you have to restart the whole process all over again. You restart it, you redo it and eventually you are successful in finishing the setting of the device. So this is pretty straightforward. I'm sure that all of you have done this at least once with some of your devices, right? So you set it up and then you start using it. Now what's happening in this last stage of the setup process is that this is the moment when everything that you've configured in the mobile app gets sent to the device. Usually this is packaged in either an XML or a JSON file that's being sent over to the device whilst your phone is still connected to that hotspot that's created by the IoT. Part of that config is the home wifi settings. So among the settings that are included in that file is your wifi SSID and your wifi password and other stuff like the friendly name calendar, email notifications. In some cases we've seen devices that ask the user for their Gmail username and password so they can send email notifications. It's bad, I know, but it's happening. So we've seen it in a number of devices. It's because they don't have an SMTP server so they want to use your Gmail account to send emails and yeah, I would advise against setting that up if you're ever faced with it because that means that you're gonna pass your Gmail credentials to the device and if the device gets hacked, they're gonna get your Gmail credentials as well. So a key thing to remember here is that that access point that the device creates in 99% of the cases is unencrypted without a password protection. It's an open wifi that anybody can connect to. And mind you, this does not mean that you as an attacker are gonna connect to the access point as we're gonna see later on, but the fact that it's open means that anybody can monitor the communications back and forth from that access point. So in a base case scenario, that config file that JSON or XML is encrypted. So even though you can see the communication, you're not gonna be able to see the contents of that config file in order to steal personal information. Mind you that this doesn't happen a lot. So this, as I'm saying, is a base case scenario because for most vendors, they're just simply sending it in plain text. But in some particular vendors, mostly the good ones with some reputation, they do encrypt it, there's a strong key and you're not able to extract the information because you need to have that key to decrypt the file. But that's not necessarily the end of the world from an attacker's standpoint as we're going to see later on. So what you're going to do is set up a wireless card, set it up on the same channel as the awesome secure IoT wifi. You don't need to join the network. You're gonna start seeing the traffic from that network just by having the antenna on the same channel, is it? Start Wireshark and profit. As a particular case, I promise that I will touch on the encryption part. We published two advisories. One was in August Connect, the August smart lock. I'm sure that you're familiar with it. And the other one in Ring Doorbell, both are fixed now. Mind you, these vendors, thankfully, had a very prompt response. They fixed the stuff quickly. They pushed the updates and everything is okay now. The vulnerability in August Connect was particularly cool. Essentially, they had that payload that's being sent from the mobile app to the device. They had it encrypted. However, the encryption key was hard-coded in the mobile app. And then, unfortunately, it was the same encryption key across all mobile apps. So if you collected the encryption key from one app, then you could use it to decrypt the payloads from all the other August Connects that are in the market. That's fixed now. Each setup process has their own unique encryption key, so that's okay now. Yeah, many people said that this is not necessarily the coolest attack vector because the setup process only happens once. So most companies rely, the security of the setup process relies on the fact that it's only happening once when you set it up. And then you don't need to do it again. So yeah, you need as an attacker to catch that window of vulnerability when the user sets up the device. However, as we're going to see, that can be mitigated. Yes, you guessed it. You just send the authentication packets to the device, you knock it off the network, and then you force the user into reconfiguring it. And if you're not familiar with what the authentication packets are, it's a standard in the Wi-Fi protocol that enables somebody, anybody, with an antenna close by, they don't need to be part of the network, they don't need to join the Wi-Fi network, none of that stuff. But anybody can knock out a device from a Wi-Fi network. You see all the MAC addresses connected to an access point, and then you just simply send the authentication packets to a MAC address, and that device with that MAC address is gonna be disconnected from the Wi-Fi network. And essentially what you're going to do is just keep doing that until the user believes that the device is broken, resets it to factory settings, and restarts the configuration process. So for that, we've prepared a small demo in the context of actually August lock. So here we see wires are being started. The first thing that we're doing is just seeing what's on the network. And here we see that our target is the beauty salon, Afrodite beauty salon. And we see the access points MAC address. And then we start to see what devices talk to that access point. And at some point we're going to see our target. And right now what we want to do is just knock out the target from the network. So we're gonna send the authentication packets to the target and kill it. So in parallel we're going to start another air dump to monitor what's happening in the Wi-Fi spectrum because at this point the user is gonna get pissed off and reconfigure the device. So we should see the access point of the IoT popping up. And there it is. August won't connect. So at this point the user has started the setup process. And now what we're doing is just we're raising an antenna on the channel. In this case it's channel five. And monitoring the traffic that's being done by that access point. So we're just watching what's happening between the IoT in the setup mode and the rest of the world. And now we're going to see the packets being exchanged from the mobile app to the IoT. We're just monitoring on HTTP because most of the stuff is happening over HTTP protocol, the smart devices, small web server that receives the configuration file. And in a few seconds, and there we have it. We just follow the TCP stream. And mind you, this is on hard mode so to speak because this package is gonna be encrypted. But as I said, we already had the decryption key because it was hard coded in a mobile app. And we're just gonna decrypt that configuration package. Packet. Actually package is not wrong. And there we have it. We have the Wi-Fi password that was being sent and the SSID. So you see that the configuration that was being sent to the IoT was this is the beauty salon for the IoT. And the password is, well the translation would be beauty without wrinkles of the Wi-Fi password. Obviously this is something that we set up for fun and games. Anyway, so this is how you hijack the password of a smart device by exploiting the setup process. Moving on, my personal favorite. Abusing cloud implementations to get RC. So what's happening with cloud implementations in IoT is this. This is the way a smart device communicates with the mobile app. You have the mobile app with you when you're roaming outside of your house, maybe in another country, whatever. And then you have the cloud that's really in the communication between the smart device and the mobile app. And there are a number of applications, protocols, systems that do that from MQTT to custom made web services that enable that. But in this particular case, what we want to exploit is some parsers that parse input from the mobile app. So what's happening is that the mobile app tells the device, open the door, close the door, change the setting, turn the lights on, turn the lights off, schedule vacuuming the house or stuff like that. Which you're doing remotely from the mobile app. And all of these can be treated as inputs by the parsers on the IoT. So the mobile app talks to the cloud, the smart device talks to the cloud and asks the cloud, do I have new configurations? Is my owner telling me to do anything? And then the cloud says, yeah, sure, here's the new config, here's the new commands that you're getting to the device. So now in this scenario, we have the mobile app outside of the house. We have the device behind NAT, so behind firewalls. It can be behind three routers, it doesn't matter because the device is gonna get input from the cloud. And you have that config file which is relayed by the cloud to the smart device. The thing that we want to exploit here are the local parsers that process that input from the mobile app. Because when you change a setting, all that thing is processed by code on the device. And since it's processed by lines of code, if that line of code is not properly written, it can lead to command injections, it can lead to buffer overflows. And a little known fact is that in IoT, buffer overflows lead to predictable remote code execution. Because ASLR is not enabled in the IoT space. The operating systems in IoT support ASLR. However, the binaries are compiled without positioning dependent executable support. So in 99%, we haven't met an IoT that made use of ASLR yet. And we've studied like a few dozens of them. So if you find a buffer overflow in the code, then that can lead to a predictable remote command execution. Case in point, the Erie Max Smart Power Outlet is still not patched. I mean, it is patched, but nobody applied the patch because the update process in the Erie Max Smart Power Outlet is very not, it's not user friendly at all. So up until today, if you know somebody that owns an Erie Max Smart Power Outlet, you're gonna be able to achieve a very predictable, very easy remote command execution on their devices from anywhere in the world. I would advise against it obviously because it wouldn't be ethical and I would advise you to tell them about it. The full details about this or on labs.bedefender.com, just search for the Erie Max paper and you're gonna have the full details on how to exploit this ability there. It's a command injection in one of the functions on the device. Guardzilla also had both buffer overflows and command injection in some of their devices. Unfortunately, the company and their cloud died during the pandemic. And as I was saying, the attack vector is that you relay your payload, whatever you want to use to exploit the processors, the code that processes the data on the device, you relay it through the cloud and wait. And obviously the command that you're going to want, you're gonna want to execute is a connect back shell. Since just by opening Telnet, for example, on the device it's not gonna do you any good if you're outside of the network, what you're gonna want to tell the device to do is just pop up a connect back shell to a handler that you're gonna keep on a remote server. So a quick demo on this part as well. We're gonna use actually the Eddy Max Smart Power Outlet. This is a presentation that I've done in Beijing a while back. Here you can see we have a MetaSplit handler that, hang on. So we have a MetaSplit handler that it's for the MIPS architecture because the Power Outlet is the MIPS architecture. It's a remote server. It's one of my VPS servers. And our goal is to tell the Power Outlet to download the first staging script, execute that script. And that script is going to be to download our MetaSplit payload and connect back to us. So this is a more detailed presentation that I've done. I would advise that you get the paper on it. It's pretty cool. The reason for that, for example, is a trivia. The reason for that weird domain, uy.md is because this string would be the password that we're going to set. There's command injection. They're using MD5 on the password. So that's our command injection. But this cannot be larger than 32 characters. So this is why we had to do a staging exploitation. So the script is going to tell the device to connect, get this A script. And this A script is gonna be telling the device to do more things, like get the MetaSplit payload, execute it, and more things. Now we're monitoring the FTP server to see if the device is gonna get the script. You can see it got the A script, executed it. The A script told it to get the other executable and then we got a shell. Just for fun and games, we're gonna run a few commands. Where am I in root? We're gonna get the wifi password from the config. This is the IP address. You can see it's a local IP address behind that. So yeah, this is the time I got a root shell on a device behind two firewalls. This was actually in our office in Romania, in Cluj. And I got to connect the shell on my VPS in Canada on a stage in China. So pretty cool. So moving on, another common vulnerability is MQTT. So MQTT is something that I personally wasn't familiar with until we started researching IoTs. MQTT is this very quick notifications and configuration servicing that can relay notifications and quick configs between the mobile app and the IoT. And MQTT has sort of a tree structure in the sense that it's usually not password protected. There's very rarely authentication on it. Or if there is, you're gonna be in the same, let's say pool of users as the other users of that MQTT server. So let's see that it does require authentication, but you are a registered user of that service. You want to see the status and the notifications of your own device. Now, what happens is that MQTT suffers from something like a directory traversal, if you will, in which if you're not configuring it properly, you can register to see the status and the formation about your own devices, but you can also go a few tiers up a few levels higher and register to the root of the MQTT tree and start receiving notifications about all the devices registered in that MQTT server. And that's gonna expose a lot of sensitive information like for starters, I'm up, I'm down, but then you get stuff like the IDs that are being used for devices by the manufacturers. And that's a very valuable information because very often the one thing that you need to interact with the device from another user is just that device ID. It's made in a non-predictable fashion, usually 16-bit format, but with MQTT, you can get that information through the MQTT stream. And we're actually going to see, we're going to see an implementation or broken implementation of MQTT later on. But play with it, research it again. We have a few papers on MQTT as well and some manufacturers look it up on our website. Another very common one, and this, as you probably many of you know, it's not just in the IOT case, it's bad implementations of S3. So S3, the storage service from Amazon. The usually the way it works is that I'm the device, let's say I'm a security camera, I'm creating a recording and I'm uploading it to slash vendor, slash my device ID, slash date, slash timestamp dot MP4. And I'm relaying that information to my owner's mobile app and telling them, I have this recording at this path and the owner can access the recording because they know the path to that recording. And in a normal implementation of S3, if you want to list the other contents of the folder, you shouldn't be able to let alone, you shouldn't be able to go up one level and list the contents of the higher directory. And in no way, shape or form, should you be able to list recursively all the contents of the bucket of that vendor. It's mostly something like directory index in web servers. Well, bad implementations of S3, that actually led to a lot of websites getting hacked as well is when an attacker is simply able to recursively list all the contents of the vendor's bucket. If you want to Google, for example, database leaked S3 bucket, you're gonna get so many hits about so many websites that had their users' databases exposed to the internet through S3 buckets. So the new release that we're, I don't think it's published yet at the moment when I recording this, but it should be published by the moment Defconn is live. If not, I'm sorry, I apologize. But it's gonna be published soon, so just monitor our blog to see it. It's Victor Cam. So spoiler alert, this release is going to include information leak, unauthorized access to the video feeds and pre-authentication, remote code execution. So a few words, it's an average, decently priced baby monitor. It has cloud support like most IoT's have today. You can access it from anywhere. And it runs on three platforms, depending on the model, IP6360, Nui and Tuya. Now, mind you, most of these IoT platforms are great inventions, they're great. However, the security reviews of these are lacking. So there's not many people doing security reviews for these cloud platforms. There's not many people doing security reviews on the binaries and the firmware running on these devices and the way they communicate with the cloud. We've been doing it. There's a few others that have, but I encourage that more of you start exploring this part. These are low hanging fruits if you wanna publish a research paper, trust me. You're gonna find a trove of vulnerabilities, including in big brands. If you just research this part, the way the mobile app talks to the cloud, you're gonna find indirect object references, you're gonna find directory traversal, you're gonna find the buffer overflows, man injections, you name it. All you gotta do is just look at the way the mobile app talks to the cloud and the way that cloud relays the information to the device. So the first vulnerability is an unauthenticated MQTT information link. So the camera uses the MQTT protocol to announce the status and to receive a URL location where it's going to send the video stream. So essentially when the camera is on, it needs to know where to publish the video stream and the MQTT protocol is the one that relays that information to the camera. Now, what we've discovered is that the MQTT server is at this IP address, so eup2p01.govicture.com on port 1883. And it has no authentication, by the way. So all you gotta do is use an MQTT client and subscribe to slash device slash the init topic and you're going to see all the IDs of all the devices that come online. So just connect to that IP address, that domain, that host, subscribe to the slash device slash init and you're going to see all the IDs of all the devices that come online. And as I was saying, there's no authentication necessary. And this is how the almighty exploit looks like. You get the tool is called Mosquito that's underlined sub. You use the host as a parameter, the port as another parameter and the topic that you're going to subscribe to slash the device slash init. And instantly you're going to see notifications from the devices. And this is bad because as I was saying that device ID is a critical, critically private information in most IOT implementations. If you get a device ID, in most cases you're not gonna need anything else to be able to interact with it. Even though obviously it doesn't belong to you, it belongs to somebody else. So the second thing that we wanted to do is get the video feed. Obviously without having to authenticate. So get a video feed of our camera as from an attacker standpoint. So we noticed that the way it works is that through the MQTT server the camera is told where to upload its video feed. And then the MQTT server throws the mobile app. Hey, the video feed is at this IP address. So we figured why don't we try to see what functions are exposed by the MQTT server besides, you know, I'm on, I'm off and these kind of things. And we discovered another function called command where we could use that to configure new parameters and new things on the camera. And among those we could tell the camera to upload the video feed at a different location. So as I was saying, the MQTT server has no authentication. All you need is a device ID which you can get from that previous step. You just register to slash device slash in it. And you're going to see all the device IDs registered in that MQTT stream. And then you just pick a device ID, send a command to it. So you tell MQTT to tell slash device slash ID slash CMD and tell it to upload the video feed rather than its default location. Just upload it to your own, to your own server. And on your own server you just have to register a small listener and you're going to start receiving the video feed. So as a demo, so in the first step we started to, we built our own web server, our own RSTP server. In this step, we're telling the MQTT server to tell our device ID so to our camera that the new URL for the RSTP server is our rogue, our attacker server. And again, no authentication necessary. All you need to do is your victim's device ID. So the command was sent and now we're waiting and we start receiving some traffic. Now we're going to pipe this so we'll also be able to see it and we're just going to open it with VLC. And there we have it. So this is the video feed uploaded to our own rogue attacker web server by the victim device that was tricked into using another location for the video feed. Moving on, no good deathcom presentation is good enough without a remote command execution. And much like with all the other stuff that we've hacked, this remote command execution works from anywhere in the world on all the devices registered by this vendor. And when we last look, I think there were about 10 million downloads of their mobile application on Google Play. So there's quite a lot of potential victims here. Now, the function that processes the URL command that's received through the MQTT is vulnerable to a stack-based buffer overflow. And the almighty exploit looks like this. So we're piping everything into one small file that we're going to send. This is the entire exploit. So not very complicated. And the command that we wanted to execute is just send us a connect back shell to our attacker server. So we bought it to execute netcat, our IP address on port 4444 with a shell. We're going to relay this with MQTT to the device. So again, this all is happening from different parts of the world. So we're turning MQTT server to tell the device to execute that command. And quite quickly, we received a connect back shell from the device. And there we have it. We have a shell for remote command execution. We have a full access, full foothold into the owner of that device's house. We can then obviously pivot. We can do anything that we want in that house. You know, we can start sniffing connections. We can start looking at other devices inside a house. Unfortunately, many, in most cases actually, the home network is not treated as hostile. And the home network is treated as secure. And as such, many of the devices on people's home networks are not properly secured. And many people keep default or no passwords on their storage servers, on their media servers, on weak passwords on the router, and so on and so forth. I mean, I don't need to tell you how many things you can do if you have a shell on a Linux machine inside somebody's network. So that being said, as end nodes, the trickiest thing about cloud-related analytics, cloud-related attacks against IOTs is from a blue team perspective. It's ridiculously easy from a red team perspective. It's insanely easy. Most of the devices that we've analyzed, we've managed to get a predictable remote command execution relayed through the cloud. So again, that means that you don't need to be on the same network with the device. You don't need to be in the same zip code with the device. You can do it from another continent and get a connect back shell from somebody's device in their basement behind four firewalls. And the tricky thing is that for the blue team, for the defense team, they're insanely difficult to detect and mitigate because the traffic is encrypted. The traffic between the device and the cloud is encrypted. You're not, if you're a company, for example, it's a common practice to poison, I mean, to install your own root CA on your employees' computers. You're not gonna be able to do that with IOT in order to decrypt the traffic and do the backup inspection to pick up exploits. So you're not gonna be able to use your common tools and techniques to decrypt traffic and CA exploits because you're not gonna be able to deploy your CA on smart devices. The IP addresses used in communication are legitimate. Your anomaly detection engines are not gonna pick that up because it's a communication between the device and the cloud. You won't know about anything that was exposed or leaked by the device because, again, it's gonna look like legitimate traffic and most companies are blind to these types of attacks. And the only viable defense that I could figure out is to be able to pick up the moment when the device sends a connect back shell if the user gets a foothold on the device or maybe when it's doing traffic with their cloud at an unusual hour. But, again, this is an open case because, again, it's very tricky. Other end nodes. If you work for companies, and I'm sure most of you do, I strongly advise that you include IOTs in your security posture and that include your IP phones, PBXs, smart power outlets, smart light bulbs, smart, the climate control things. Most of the things in organizations are connected now. So just see whatever has an IP address and doesn't have a common operating system and talk to the vendor and make sure that you have a look at their security processes and definitely subject them to a pen test or ask the provider when they did their last pen test and also with what company. I remember I talked to the director of product management at one of the companies that was making a product that was ridiculously broken from a security standpoint. We hacked it in five minutes. They had, their security mechanism was something called a client ID. And if you know the client ID, then you can interact and get all the details about the client, including their devices and passwords. And that client ID was a number. And it was like a sequence of numbers. So our client ID was 308411 and then the next one was 308412 and so on and so forth. So totally ridiculous. And I asked the guy, okay, I'm not gonna blame you for doing something this ridiculous, but why didn't the pen testing company tell you about this because it's very obvious. And the guy said that they paid a lot of money for that pen test. So be mindful of who you get to do your pen tests and be very careful about that. You're gonna want all your IOTs evaluated by a red team. You're gonna want to see the pen test reports of your provider of the manufacturer of that smart device. And you're gonna want to validate the company that performed the pen test to make sure that they're on the level and they're doing a proper job. Whenever you hear somebody say military grade encryption, run away, whenever I talk to vendors, I ask them, so what steps did you take to make sure that the software running on your device is safe? And I'm actually feeding them with additional information. I'm telling them, okay, so how do you mitigate command injections? How do you mitigate buffer overflows? How do you mitigate improper segregation of user privileges and stuff like that? And like in nine out of 10 cases, the vendors tell me, we have military grade encryption. And I'm like, okay, whatever, sure. I mean, encryption is one thing, it's cool, but how do you handle application security? Application logic that's poorly designed, we have military grade encryption. So right, so when you hear people talking like that, you wanna run away. Yeah, another important thing to know about IoT is, is that many, like 80%, I would say, of the vulnerabilities that are discovered in the IoT space are not tracked by CVs. So if you use tools that correlate with CV details or CV.mitter.org or whatever, you're gonna be blind to about 80% of the vulnerabilities in the IoT space. So only like 20, 30% at best of the vulnerabilities in the IoT space are tracked with CVs. Make sure that you run security audits on all of smart devices. I've mentioned this, I'm gonna mention it again, and this includes your industrial devices, if you have them, even if you have like those solar panels or whatever power generators in these day and age, all of them have IP addresses, you're gonna want to make sure that they have been, they've gone through a security test before you start relying on them. Pretty much, this is it, I guess, so purchase any devices for connectivity only from trusted providers with reasonable SLA. This is pretty much what I've said earlier. You're gonna want to evaluate your vendors. And actually one last thing that's extremely important. Again, taking the opportunity to push for better standards and accountability from vendors. So for example, my suggestion would be that a very simple law could be put in place that forces any company that handles customer information or that has any kind of responsibility to have a security contact. It's as simple as that. You don't have a security contact and you don't reply to security researchers, you shouldn't be able to operate. We're doing this for free. I mean, we're not even doing it for the bug bounty. So a number of us are actually doing vulnerability research for free and vendors just don't even have a link that we can use to send them our vulnerability reports. And because of that, a huge number of users, tens of millions, hundreds of millions are exposed even today, even though we know about the vulnerability and we want them fixed. A huge number of our papers, like 60% of our papers are still on hold and we cannot publish because publishing them has a potential to create chaos in the internet and the vendors that make those devices just didn't reply to our emails. So with that in mind, I want to thank you all for watching my presentation. I hope you enjoyed it. I'm available for Q&A, I'm also gonna be on site at Defcon if you wanna give me a sign and say hi, grab a drink, I'm fully vaccinated. So this is my contacts, I'm on Twitter, my handle is Jamesu and you can check out all our papers at labs.pedefender.com. So thank you all for watching. I hope that I'm gonna see some of you on site at Defcon. Take care.