 All right, I think we get started. If this is not loud enough, let me know. Just remind me of it. I hope it works. And if anything should not be large enough, also just let me know I can always zoom in. But I hope this should all work out. So I'm here today because I am releasing the first real release of Enzyme, which is a tool I've been working on for, I think, two or three years now. And I'm gonna go through what it is, what it does. And I wanted to check first, has anyone heard about the tool before? Because there is a released version already. Let's see a few hands going up, okay. And I'll try to also cover kind of a few basics of how wireless networks work and what some problems with the security of those networks are. You can always either interrupt me if something is completely unclear. And I think we'll also have a good amount of time for question and answer after this talk. So just a few things about me. I'm from Germany originally, but you can probably hear it. I did start the Greylock project back in 2009. We actually had a birthday party here in Vegas this year. It was 10 years ago. Then a company behind it in 2013 and moved from Hamburg in Germany to Houston in 2015, which was an interesting move for sure. Started Enzyme in 2017 and had an initial release in the same year. I think I released it around DerbyCon 2017. Used to be a software developer. Gonna make some people smile up front here because they used to be software developers together with me. I'm the CTO and the founder over at Greylock now. This word Greylock is gonna come up a few times. It's very important that I'm gonna show Greylock because that's the tool I'm obviously the most familiar with. You can possibly do the same things with an elk stack or a Splunk or something like that if you send the data into that instead of Greylock. So don't consider this a vendor talk or something. This is just the tool I'm obviously the most familiar with. And Enzyme is my site project. It's not affiliated with Greylock. I'm saying that because you should not expect the same level of support and help and everything that comes from a company like Greylock because it would probably be very easy to expect that. It's my site project. I'm personally, I'm a huge fan of site projects because when you make the transition from being a developer to being more of a manager and you're managing other engineers, it's very helpful to have something that you're still building yourself because it reminds you constantly of the challenges that software developers are facing and I think it helps a lot when you work together with them. So that kind of keeps me in the loop. The trick is to never have that actually interfere with what your real job is. So it's mostly a weekend, holiday, after work kind of thing when I really want to write some lines of code. I'm at underscore Leonard on Twitter. I was specifically asked to point out that my last name is Koopman and I'm not affiliated with SystemD either. That I was asked to say that. So I'm making this joke every single time. I'm starting to get tired of it myself but I spent a lot of time for the second picture that's about to come. This is Hamburg, moved from there. Did this. And then moved there to Houston. So we are, Greylog itself is based in Houston. I live in Houston. It's kind of a little bit of a background of what happened in the last years here. I'm going to go over just a quick introduction about what enzyme is, what it does and also what it's not. Few things about architecture, deployment, configuration. This is not going to be a tutorial. I just want to give you an impression of how you set it up and how it's architected. We're going to go over some detection methods, some threat hunting that you can do with it. And then I think the biggest part of this presentation today is going to be a live demo actually. And then after that we're going to have Q and A. I want to say a few things about what I really want to work on after this. So what's going to come after this initial release and where you can actually download it and all these fun things. So I tried to summarize this in one sentence and I ended up with this whole slide. So enzyme is an open source tool that reads Wi-Fi frames using network adapters. So I guess a bunch of you in this village here will know these little alpha network adapters. You can put them in monitor mode and they will, it's almost like a promiscuous mode on a wired network interface where they're just going to read everything that comes in and you can use a TCP dump or wire shark or tools like that to read these frames that are going through the air. Enzyme is reading every single management frame that is going over the air and it is parsing it and it's sending it to a gray lock instance. Like I said, if you put a lock stash in the middle you can send that anywhere else too. And that means that you're going to end up with a repository of frames that were recorded in a lock management system that you can then later search over, filter, use for forensics, use for incident response because I think that if you catch someone who's walking around with a, I don't know, with a Wi-Fi pineapple or someone is actually targeting people very specifically in the parking lot, I think we're all struggling then with, okay, what are we going to do next, right? You know that, but what actually happened? Who did someone connect to it? Was only one specific device targeted? Was it just spraying SSIDs? Was hoping someone connects to it? This is something that you can do the moment you send this stuff into a lock management system. And that's pretty much what Enzyme used to do. That's what the currently released version of Enzyme does. This new release that is coming out now is also allowing you to raise alerts automatically. So it does things that are very similar to what I think what Kismet does. Why it's not Kismet is however on the next slide. It, you can run it on a Raspberry Pi, it comes with a web interface and it's not only employing, I would say these classic signature-based alerts of, well I'm expecting this SSID to only be served by access points with these MAC addresses and then when another MAC address pops up, I get an alert. It does that too, but I think that is so easy to evade that I don't think that's enough anymore. So it does a few more things that I'm going to go over in just a moment too. And then I always, I'm a big fan of having stuff that's easy to be deployed and easy to be configured. That's actually something that if you go out and you want to try this out, I'm very interested in where you, if you get stuck somewhere if something was confusing because I hope that the configuration is fairly easy. But then I wrote it, so for me it's fairly easy. I hope that it's also easy for you. I'm running this in production for a while now at home and in the office and we are over at the Blue Team Village. There's a sensor running under a table. It runs pretty stable and it runs really well on a Raspberry Pi 3. I'm also running it on one of the new Raspberry Pi's, the fours. That's better, it's going to be faster and especially for an environment like here where you just have a lot of stuff going on, a lot of devices, a lot of access points. If you can get a Raspberry Pi 4, that might be a good idea. Because what it's not, it is definitely not designed to have a low resource footprint. As in, I'm not saying I'm just wasting resources for fun, but it does a bunch of stuff that are simply resource intensive. That means that if you're looking for something that you can deploy on a tiny embedded system or something like that, this is not it. This needs probably around at least 256 megabytes of memory. Probably a good idea to have at least two CPU cores, like I said, runs on a Raspberry Pi, not gonna run on one of the small hack five devices, for example, that's probably not gonna be enough. And then it's also not designed to be used for any kind of war driving or reconnaissance tasks or something like that. It's supposed to be run stationary at one point, not be moved around a lot. It really likes to be in a somewhat predictable environment. I'm gonna show why in just a second. So it's also nothing with you. I had one feature request if we can hook up a GPS receiver into it, probably could, but the whole system is not designed to be used to walk around with basically. I have heard or I've found this interesting that red teams were interested to use it for recon, not for alerting necessarily, but to send, basically point a Yagi antenna or something at an object that they're looking at and just record a few hours of data and see what is usually connecting to what, what kind of devices do we have, what SSIDs are they looking for. I could totally see that and that would be something that would definitely work. I just, I've never heard this from more than one person so I'm not sure if that's actually the case or if there's better tools for that out there. This is a screenshot. So this is the web interface that comes with it. This is being served out of the same binary as Enzyme itself. So when you start it, it just tells you, hey, on this IP address in this port, you can reach the web interface. Supports TLS on top of it so you don't have to mess with like a proxy in front of it and I'm gonna show more of this in the live demo in just a second. This is a network detail page. You see here we're recording the beacon rate of this specific access point and the SSID that it's advertising and then we got a list of all the channels and you see that we have a, there's a red line that is the, that is the upper expected signal strength. We have a green line that's the lower expected signal strength and then we got the blue line that's the actual signal strength that we're receiving. Also more about that in just one second. The architecture in the end is pretty simple. You have the Enzyme process. That's the binary you're starting. That's connecting to a PostgreSQL database. That's where it's keeping state and also some information that it's using later for alerting and then to whatever box this is running on you're collecting, you're connecting at least one Wi-Fi interface that supports monitor mode. Works fantastic with the standard Alpha adapters. I think it works great with a Panda 5 and a Panda 6. Those are gonna work. You don't have to do anything as long as the interface is up. Enzyme is automatically gonna put it into monitor mode. It's gonna get a P-CAP handle on top of it and it's gonna start reading the frames that are coming off the air. I'm gonna show the configuration of this also in just a second. And then there's the Greylock cluster. This one is by the way that's optional. You can also start it simply not connected to Greylock. If you don't wanna have the part where it sends messages into Greylock, that's fine. You don't need to do that. Then just leave that configuration out and it's just gonna run and everything's locally and you don't have this long-term repository of frames basically, which is completely fine. Depends on your use case. If you wanna try this out, maybe download the Greylock OVA or an Elkstack or Splunk or whatever you have already sent it in there and just see what you get out of it. Really interested in the use cases that you also find for this. I said this was not gonna be a tutorial but I just wanted to show you that this is literally all you have to do to get it running on a Raspberry Pi. So you just install PostgresGL, you're gonna install Java. That's what it's written in. You're downloading the depth file, you're installing it, you're changing the configuration file and you start it. That's all you have to do. It's gonna tell you when it starts up, it's gonna tell you where to point your browser at, you configure the interface that it's gonna listen on in the configuration file and that's all you need to do. That's how fast it is usually. And it's one other important thing which I might remember later on but that's really the steps that you need to do to deploy it. I'm wondering where the, oh yeah, split this up. So going through the detection methods that it has out of the box, these are these really, really classic alerts. There's an unexpected MAC address that's serving our network. It's serving it with an unexpected security setting, serving it on an unexpected channel or there is an access point that is serving in an unexpected SSID. What you have to do is you tell enzyme in the configuration file, that's the screenshot down there. You basically give it a list of its networks, that's this array there that's defined there and you tell it, okay, this is one network, this is its SSID, this is the channels it's usually running on, this is the security that I'm expecting on it and these are the BSSID, so the station MAC address is basically that it's being served from. That's all you do, you start enzyme and the alerts for this are already set up. It does everything behind the scenes automatically for you. Do you see the fingerprints in there? I'm gonna explain that also in just a second. I'm calling this anomaly detection, it's not, I mean this is a little like standing and telling you about AI and next-gen security. It basically looks at a sliding window of what the signal strength was and the moment the signal strength deviates from its expected value too much or for too long, it's gonna raise an alert. This could be that after we record for a day what this access point up there usually reaches our enzyme sensor with from a signal strength perspective. If someone is spoofing that from across the hallway even if they're perfectly spoofing it, it's really hard to spoof the signal strength. So you're gonna have in between all these expected frames there's gonna be perfectly spoofed frames that have a much different signal strength and enzyme is trying to figure this out and is trying to find those and it's gonna automatically for all the networks that you defined as your networks in that configuration file, it's gonna run in the background constantly checking if there's like anything going on with a weird signal strength. That is still fairly experimental because I wanna see how it works in the real world if you try it out. It has worked pretty well for me so far but there are some tuning parameters. It's not gonna, if you turn it on out of the box you're probably gonna get a bunch of false positives. So you have to tune these parameters a little and just see how the data behaves. But I've tried it out. I walked in the garden with a raspberry pipe, turned that thing on, came back, alert was there, signal strength anomaly. So it can work. I wanna hear how it actually works for you in practice if you wanna try it out. So just consider it experimental for now. The other one is an unexpected beacon rate. So we're constantly recording how many beacons we're getting from per station or per access point. If someone will go in and would start to very aggressively send its own beacons that would raise this beacon rate even if the frames are, again, if they are really well spoofed, the beacon rate would change and Graylock would also alert on that on a threshold basis. For this, it's not trying to do this automatically for you. You give it a threshold, you say this is how many beacons we're usually seeing and then the moment it crosses over there for too long you're getting an alert. That works really well. It depends a little on the access point that you're using. If the access point starts to change the beacon rate a lot then you might be out of luck for that. But for those that I've tried it with so far it worked really well. Then there's fingerprinting. That is something that is the most interesting part, I think, of the new version of enzyme. So what happens is that when we receive a beacon frame or probe response frames, those are the true frame types that are really advertising in network. So this access point up there is constantly sending beacon frames saying, I am here, these are my settings, this is how you connect to me, this is my SSID, and this is how on your phone, for example, the list of access points and range is being built. Appropriate response is when your phone asks for, hey, is this network in range? Then this device might reply and say like, yes, I'm here and it can connect. So these are the true frame types that are advertising in network and they have in their payload. If you look at Wireshark and you look at the details in the payload there is a part of the payload that's called attack parameters. And attack parameters are stuff like, hey, I'm this access point and I'm operating on these frequencies. I'm using these channels. So don't even try to connect on other channels. There's stuff in it like this is my regulatory domain. I'm in the North American regulatory domain, so I'm not even gonna be on, I believe, channel 14. These are my security settings. These are my encryption options, all of that. And that usually doesn't change. And if you take that, parse it out and basically hash the result of all of that, you get a fingerprint. And this fingerprint is actually very, very, very, very different per device. So I've not yet seen the fingerprint been the same twice or have seen a collision, which means that this device over there has a fingerprint like what you see over there and we can identify it by that. Now every other device from the same vendor with the same firmware on the same chipset and the same network settings is also gonna have the same fingerprint. But we can now say, okay, for my network, I'm expecting this fingerprint. If I'm seeing another fingerprint, this is simply a different hardware, different chipset, a different firmware that is trying to advertise my network here. That is certainly not good. And the cool thing is that you can actually fingerprint known bad devices. So a pineapple nano management access point, that's its fingerprint. And I've not seen that anywhere else yet. That is only a Wi-Fi pineapple nano management access point. So it comes with a list of, I believe, probably six or seven of these devices that it automatically identifies. So if someone should own a Wi-Fi pineapple in this room, I challenge you to later turn that on when we're in the demo. It should immediately pop up and say, there's a Wi-Fi pineapple somewhere around here. It does that also for de-author boards. For that one, I'm still trying to see if that's really the de-author or if it's just the ESP-8266 chip on it. I think there might be some false positives on that one. But it works with Wi-Fi Fisher, the pineapple nano and the pineapple, like the larger one, the tetra or whatever they call it. It will identify those automatically before you when someone turns them on. But we'll see that in the demo. Then there's deception. That's one more thing they've built into it. Which is basically, if you add another Wi-Fi adapter, that also supports packet injection or frame injection, which there's a list in the README that tells you which ones do. And most of the alphas in the pandas do, so it's no longer a problem. Enzyme is actually going to start sending probe requests. So Enzyme is gonna act like an iPhone, for example, and saying, hey, I'm looking for these networks. Is any of those in range? And none of those networks actually exist. You configure them like this, and you basically say, fake this transmitter MAC address and start looking for these SSIDs. If anything replies to that, that's not good, because those don't exist. There's no legit reason for anything to reply to that. Except if you're at an airport, then you might sniff up a United Wi-Fi sometimes. But if you're somewhere in the middle of nowhere and off, it's probably not gonna happen. And you can craft these SSIDs in a way that you might even attract attention of an attacker. Like, for example, you could fake an high-risk employee iPhone. You look for the corporate network of three different locations in San Francisco, somewhere in Asia and somewhere in New York City. You're looking for all the airport lounges, and you're looking for all the United Wi-Fis and all of that stuff. And for an attacker, when that person spins up, his attack platform, it's gonna see like, this is a very interesting phone. Let's see if we can answer to some of those, except none of those actually exist, you know? So if that happens, that is a pretty clear indication that someone's trying to lure someone to connect to a rogue access point. For this to work, that's all you need to do. That's in the enzyme conflict file. You basically just tell it what's the device name of the device that's sending, which channels you wanna send on, and then you define these, I call it traps. You're literally setting up traps of non-legit networks, and if anyone starts interacting with that, now you wanna go in your log management system and see, okay, who is that? What's the signal strength? Is that person moving? Has that person been here before? Who else is he targeting? You can do all those things. So that's when it really starts to come together. And then you can, of course, I think I talked about this a little bit already. If an attack was detected, you could use a log management system like Greylock and go in and figure out what exactly happened. Who connected to this? Was this very targeted, or was someone just spraying responses and beacons hoping that something happens? So we're gonna do a live demo. Here we go. My friend up here in the first row probably knows that I spent most of the time in software projects finding background images for login pages. It's kind of what I do. So it's fully authenticated. If you dive into the code, you'll see that a lot of it is weirdly similar to how Greylock is architected. So it's very similar. It's fully authenticated. Enzyme is basically spinning up REST APIs that you can only connect to if you have a token. Token is exchanged here during login. And so you can interact with it through APIs too because this is really just a React JavaScript-based web application that's just firing out REST requests. So if you wanna automate anything, if you wanna build your own interface, if you wanna build a CLI interface, all these APIs are there because Enzyme itself is using them. So if I log in here, what you're seeing basically, hi, here we go. There's the alerts. I expected that if I start this up in here, I'll probably get an alert or two. So this is all running locally because I turned off pretty much all the network on this device here earlier today. So I only have these charts look weird because I started up, I shut it down. And then I think we have about half an hour of constant data going on here right now. But what you see is we've collected about 83,000 wireless frames so far. We're seeing about 428 distinct clients right now and about 238 access points. I don't think that there's actually 238 access points in range because what we see here already, these are the active alerts. We see all these known fingerprints. If I click on one, this one, for example, you'll see that the SSID Bravo, which is one of those, I don't know, I only see those during DEF CON, one of those that around here was advertised by one of these D-Authing boards. It just detected that, spins up and sees, I know that fingerprint, that's no good. And we see it was on Channel 11. We get an antenna signal here and we also see that that's the fingerprint of the device that does it. I think we're getting pretty much flooded here right now with this, which I expected, honestly. But we can go into Greylog and see what exactly it is. This one here, for example, is Wi-Fi, Pineapple, Nano or Tetra. For those two, we can't really distinguish which one it is, but it's definitely one of the attack frames, which means it's a beacon that comes out of the Pineapple firmware frame injection, which is this one here, which I think from the SSID, we can see that this is probably really not a legitimate network we want to connect to, right? So that's the overview here. We see here, this is the channels that we're currently looping over. When it's highlighted blue, that means that the adapter is currently tuned to that channel. So you see life, kind of, which channels we're currently hopping over. We see how many malformed frames we're getting per channel and then we also see how many different frame types we're getting and as expected, we're getting mostly beacons and probe responses and then a bunch of de-auth frames, obviously, in this environment. To click on networks, I'm getting a list of all the wireless networks that are currently in range. Earlier when I turned it on here, I figured out we do support emojis. So someone is advertising an emoji network, so that works. We got this list here of all the networks. And if I click on one, so let's say, Caesar's Resorts. Click on it. That's loading all the channels that are in this network. You see this one is only active on channel 11. We're gonna receive two frames though, so that's boring. Let's see if we got another one. Caesar's Resorts, take this one. Click on it, we see on channel six here, we got about two and a half thousand frames that were recorded. Click on that. And then we're getting, oops. Then we're getting, this is when I started it, so it's only have a few minutes of data here. But you see per channel, you're basically getting the signal strength, what the expected signal strength was. You see the fingerprints that we see on this channel, so that's this specific access point. You see the expected signal quality. All of this is here. If I click on the system status, you'll see that we see which alerts are currently configured. You see that we would be warned if there's an unexpected BSSID, SSID or channel or fingerprint, would be warned if the crypto settings on one of our network suddenly changes. If there's a known fingerprint around here, unexpected signal print, fingerprint signal anomaly and also the beacon rate anomaly. This system, this environment here is actually so noisy that I can't, no, it stopped. All right, currently do not have any active alerts left. So they also stop. The moment the same alert is no longer seen, they disappear from that list. So this is a good moment. If someone has a pineapple, we're gonna turn that on now. This should pop up here then in just a moment. Then if we go back, I think someone turned it on for a moment because we're seeing a pretty good spike in access points. So that is simply someone using random MAC addresses probably, which then identifies a different access point all the time. So that's what we're seeing here. Now if I go into gray log, you'll see that this data is coming in here. If I click on a view, I can say, okay, I wanna get my summary of all the data that comes out of enzyme. You'll see that I'm getting a histogram here of how many deauthentication frames we've seen, how many distinct devices that were transmitting deauthentication frames. Get an overview here of the frames and subtypes that we're seeing. So there's a total number of frames that were recorded and then also which subtypes they were. So you see here we got a few malformed one, but then this association, association response, authentication, probe request, probe response, beacon. It kind of gives you an overview of what's currently going on in the environment. Then if I click on it, this is where it's now really starting to feel like this is a very long-term wire shark, you know? If I click on it, you'll see that, okay, we have recorded a probe request where this MAC address was looking for on the network alpha, which was this signal strength on this frequency. If I click on it, we're getting this broken down. Let me see if I can make this a little bigger. See, we'll see this broken down. And what I can do is I can now say, okay, I am interested in all the devices that are looking for the SSID alpha, okay? So what I can do, I can go in and I can say, okay, in my enzyme messages, show me everything from the last hour, where the subtype equals probe request and the SSID equals alpha. Execute that, this comes back immediately and now we get a list of all the probe requests for the SSID alpha. And let's say I want to get an overview of who requested this. So you'll see that we have a field here called transmitter. This is the IP address. This is the MAC address off the device that was asking for this network. And if I click on it, click on aggregate, and we're getting a list of all the MAC addresses that have probe request this SSID in the last hour. So you can click this stuff together like this. You can save it as a dashboard. You can create reports out of it, but it becomes a very, very powerful, really long-term PCAP that you can use for forensics. You can use for threat hunting. If you wanna check if something just deviates from what you'd usually see, you can go and you can run real forensics on long-term network data, which I think is a really powerful concept. And we can also go in and look at an alert summary. So this one here is now showing me when, how many alerts we got here. It shows me what the targets were. So you see here the SSIDs that were used in an attack. You can see here the types of the alerts. So you see that we had 18 alerts for known bad devices, which were 18 for Wi-Fi pineapples and five for a de-authentication board. And we had, where are we? Yeah, I think that is the types of devices that we are getting. And if we go in and we say we want to do that, we say we want to see this, this here, and also this one here, United Wi-Fi, there's someone already went into that trap, someone already triggered an alert because they responded to something that they really shouldn't be responding to. And I think we should be able to, second, see here that we're getting a alert type in here somewhere, alert type. You can aggregate that again. It's gonna give me a list of all the alert types. And there you go. We had 10 times someone trapped into the probe response trap, basically. So if I search for only that, we should be able to see when that happened and who did it, and here we go. That's the alert. This device responded to our probe request trap for CenturyLink, something for United Wi-Fi and for this fake corporate network. So you can use Greylock now or any other system to go in, get an overview of when the alerts happened, what they were about, then go deeper and investigate what exactly happened. And you can, of course, also add your own fingerprints in this list that it's constantly searching for. So if you have, I don't know, you have this one employee who's really unhappy with the Wi-Fi signal strength and they just bring their own access point, right? That has happened a few times in the past, I think. You can now just record that fingerprint of that, send an alert whenever that device is back online and you can use Greylock or anything else and just send out a text, send out an email and kind of just be alerted the moment someone turns that thing on. So there's probably also some operations use cases. I'm sure there's some red team use case for that and there's definitely a lot of Wi-Fi defense use cases for this. So that will be my quick live demo. Do not actually have any alerts right now, that's surprising. I have one more slide, I think there should be this one. That is right here. So the full release, as in the release that also has the documentation, the release that also has Debian packages, system descripts, all that fun stuff. It's happening probably on the next weekend. You can already build it yourself. It's on GitHub, that's the link down there. And you can try it out, it's on the version 1.00 branch. Like I said, it is, the software itself is done. It's just a few of the scripts around it, it still needs some testing and I simply don't want to release it in a hurry just to be able to send your link right here. So it's gonna take a few more days until you can release the full distribution. And if you don't want to forget about that, just follow me on Twitter, that's my handle there on the left. And then you should see a tweet when that thing is finally coming out in the next days. From a future roadmap perspective, so there's a few very clear things I think that need to be done. There's certainly more deception methods. I think the deception message also needs some more fine tuning because if you think about it, now an attacker could technically fingerprint us and figure out if that's a enzyme deception frame or not basically. So you wanna have a little bit of variance in there. Right now the beacon frequency or the frequency of sending these things is very stable and if you are a very sophisticated attacker, you might see that there's something going on. I do think, however, you're gonna trap a lot of people who are not expecting something like this to happen right now. But there's definitely, there's someone work that needs to be, that needs to go into that. Multi-note support, so right now it would be if you have a large campus and you can't cover everything with one enzyme node, obviously. You would spin multiple up. They don't really know about each other and they would all send their messages into Greylock. I kinda wanna get it to a point where you have one that's the leader and all the others are sending their frames into that one and that one then writes it up somewhere else to central alerting and can get smarter about when it alerts. And then I hope that you're gonna try it out and you're gonna find a bunch of bugs, feedback, maybe you get stuck somewhere. So that's definitely gonna come. And like I said, this is side project so I know this version's gonna come out over the next days. But something like multi-note support is nothing that's gonna happen the following week. So it's on GitHub, you're all more than invited to maybe contribute your own fingerprints. If you have devices out there, start fingerprinting them and send a pull request to get them in the list of known fingerprints. Try it out if you feel comfortable writing code, send pull requests for features, open tickets for stuff that you would like to see in it, stuff that doesn't work. So this is supposed to be a fully supported product. This is not something that you just throw out there and good luck. There's gonna be, I hope that there's community forming around it that keeps on improving it and it's not only me in my very spare free time. And I hope that that's gonna happen. So that will be my demo and my presentation and I think we have 15 minutes, 10, 15 minutes for Q and A if you have any questions, any feedback, any initial ideas? Yes. Sorry, got it pretty close. So the question was which adapters are supported by it and then also kind of how much space you can cover with the sensor. How much space you can cover really depends on your physical location. I had a demo labs last year for the previous version of Enzyme and there were people who said they deployed 20 of those across their campus. I think you ought to try it out and I think you want to reach a point where it has overlap where you have frames recorded multiple times because multiple Enzyme instances are picking them up. When it comes to supported devices so far, pretty much anything that works that you can put into monitor mode. So it's not specific to any device but you need to have a driver and a chip set that you can put into monitor mode. So if you have some experience with Kismet for example, I'm pretty sure that you can use the same adapter. And all those that I've tested so far work, there's a list in the documentation of tested devices that definitely work. I've seen it with several of the alphas that are the bigger ones and some of these more mobile ones, the Panda with an antenna, the Panda without an antenna. Everything that kind of works with P-CAP and monitor mode is gonna work because we really just interface with the P-CAP. So if P-CAP works, Enzyme is gonna work too. Any more questions? Okay, I'll be around at the Blue Team Village for the rest of the day but I'm also gonna hang out here for a moment if you have more questions. Try it out, follow me on Twitter so you see when the full, the easy to install release is coming out in the next days and I think that's it. Hope you enjoyed it.