 Today we're going to be talking about hunting mobile at rogue access points. And so it's kind of the same methodology but we've beefed it up just a bit. I'm Todd Parity. I'm Minnie. We're out of Colorado. We're both pen testers and we like to do stuff on the side for fun. So none of the things that we're going to talk about today reflect anything about our employers. This is all a personal project, especially any opinions or jokes we might make. These were not approved by our employers. Alright, so first of all, whenever we give this presentation we like to just set the stage so that everybody understands what we're talking about. What is a rogue access point? A rogue access point is something, is a wireless access point that's either misconfigured or maliciously configured and exists in a hardware baseline that you don't want it there. So the idea is you want to find these and get rid of them. They come in all sorts of forms. You know, you have CIS admins that set up an old Netgear router hoping to get stuff done and they leave it open. Or you have a retail shop that installs a wireless extender and they authenticate to your WPA to main hub and anybody else can access that extender because it is broadcasting open and boom, right behind the network. So these are real threats in terrestrial networks and they require some specific tactics to find out. So last year, Minnie and I talked about hunting the stationary APs. There's a link here that I guess we'll post the slides on the wireless villages page. Follow the link, watch our talk from last year. We won't talk too much about it, but this year we're talking about mobile rogue APs. These are the foxes. If you're competing in the CTF, if you've ever competed in the CTF, you know that this is one of the challenges. Go out and find a wireless access point that's roaming around. Now this presents its own challenges because in order to find it, whatever gear you have with you, that antenna pattern has to match the antenna pattern of what you're searching for. At least they have to be in the same vicinity. So you can spend a ton of time on your feet looking for a fox and never pick up its signal if you're not doing things right. And if you go back and watch our talk from last year, it's pretty much what happened. We just walked around a lot. If you think about Caesar's Palace blueprints and if you put a Roomba on that blueprint, that's pretty much what we did. It just went back and forth until we found the stationary AP. So hunting mobile APs takes on its own form because you can go back and forth just like a Roomba would to try to cover your entire search space. But if you're not in the same place as the fox, you're going to miss it. So it's attacker control. The attackers got the hardware on themselves. So for any sort of hunting, what do you need? What are the key pieces of information that you need to go out and hunt the rogue AP? You have to be able to identify your target here in the wireless CTF. The organizers post a BSS ID, and that's it. They'll just give you a BSS ID. They don't tell you the frequency. They don't tell you the channel. And you've got to go out and find it. So you have to at least start with a BSS ID. And a lot of folks will pick this up if they're doing this threat hunting for real. They'll have some indication that something's wonky in their environment. And they'll be able to pull a BSS ID. And that's what they start from. So it's better if you have a frequency in a channel because you narrow your search space. You can tune your gear a lot easier that way. But you also have to deal with a bunch of structural and wireless interference. So you may need different types of antennas, directionals. In our talk last year we talked about not using Yagis for these types of hunting. It's kind of cool. Looks cool. You're walking around this big thing that looks like a sniper rifle. But it actually makes the search a lot harder. Because remember your antennas, your radiation patterns have to overlap. And if you've got a soda straw that you're just pointing around in whatever direction, then it's going to be really difficult to find somebody else's donut. And here, especially this year for the contest, you have a huge space to cover. Last year we talked about Caesar's Palace, something like 60 acres of space, 30,000 people, 600 floors of rooms. So just tons of space to cover. And this year we're across three different casinos. So you just imagine how that scales up. So coming off our success from DC 25, finding the stationery access point, Minnie and I decided that we were done walking around. Like we were going to cut that out of our strategy immediately. I get shin splints really easy. I've got flat feet. And Minnie's got a bum knee. So we were done walking. And we thought, okay, how do we approach this in a smart way? So our idea was let's just sit still, or at least relatively still. Let's deploy some sort of sensor that can just stay in one place and somehow we get notified. Well, one way to do that is just get a huge team of people, 12 plus people, everybody gets a raspberry pie and you're on ham radio and you all go out to your different locations. Well, guess what? People are unreliable. And they suck at communicating. So we needed something that we could control, something that had a protocol that made sense to us that we could check out and would work nine times out of 10. Of course we wanted 10 out of 10, but nine times out of 10 is good enough for us. So with that in mind, traditional hunting takes walking around but using direction finding. And that's still important to us. Even though we didn't want to walk around, we had to eventually use traditional methods. So the idea is once we deploy an automated non-human sensor network and at this point we still didn't know what that would be, we're going to narrow down our search space and be notified where we need to be next and hopefully we're somewhat close to where we need to be next. And we thought that might make things just a little more efficient. So another thing that we needed to make sure is that we kept our costs down. Like I said at the beginning, Mini and I bankrolled this whole project ourselves and we're pretty poor, so we had to keep all of our costs down. Also we had to keep our costs down for this last point because we needed to make these things concealable. At least to compete in the wireless CTF, we wanted to be able to place whatever these sensors would be, we wanted to be able to place some places that we didn't have to have physical security over. That we could just leave them there. And it's DEF CON, there's a bunch of thievery happening here. If you guys see things on the walls or on tables, you're probably going to pick it up. Now this is important because we could have built out this whole strategy I've described so far by just buying a bunch of Aruba access points or Cisco Enterprise access points because they have this functionality built into them. If you deploy enough of them, you have about a two dimensional heat map and you can see relatively where specific users, specific access points are. But at $500 to $1500 a wireless access point, we didn't want those just walking off here at DEF CON. So our approach was a low cost, rapid prototype of a deployable and unmanned sensor network. So after doing some research trying to figure out what devices kind of fit that model, we came across the ESP8266. How many of you ever played around with this before? It's gaining popularity. The ESP family of wireless chips has been around at least the DEF CON scene for a long time. The last several years, some of the badges have featured ESPs, ESP32s and then obviously a lot of the indie badges feature that same chip. There's a lot of functionality in them. For us, the ESP32 is a little more expensive than what we wanted. I think it came in at about a $15 a node price and we wanted to keep costs extremely low. So if you see here, it's three bucks. Get it on Amazon, you know, $3, no big deal. And that was the building block for our whole sensor network. These were released in 2014. Somebody out of China was manufacturing them. Nobody here really caught wind of it except if you were like really into hardware hacking. And then Hackaday picked up the ESP8266 for one of their pieces. And it was a great article on what they were able to do with the 8266 because it's pretty unique. You know, at $3 you get almost 20 dB out of this tiny little chip that's powered by 3.3 volts. So in open space, some people have done tests and it reaches client to the wireless access point is about 300 meters. So it's got a really, really good radiation pattern. And even better in the chip is all the functionality that you need to run WPA and WPA2. So that meant that we didn't have to write that from scratch, which was really important for me because I'm a horrible coder. Really important for Mini because I didn't want to turn them into a slave during this project. So the ESP8266 has two GPIO transmit and receive serial pins. This is really neat for debugging because we can just see, we can print stuff out just like really rudimentary debugging, entering our own print line, seeing what's going on. But it also allows us to combine multiple ESPs if we wanted to, or put other sorts of sensors on it so that we can read and control what's going on. So this quickly became our number one choice for how we would build this network out. It's got a 32-bit risk processor on it. You can overclock it up to 160 megahertz. And one of the limitations is it only has a meg of RAM and that's for both program code and user data. So that may not seem like it now, but when you're dealing with wireless stuff, that's very small. So our ability to just dump a bunch of logic onto this is slim. It runs on 3.3 volts, which means you can power it with a, you know, just a little tiny coin cell. A lot of the projects that you'll find online for 8266 is a bunch of IoT stuff. Farmers who are monitoring their water flows and folks who are watering plants and a lot of watering going on with 8266s because they act as a wireless access point themselves and they run natively. If you just bought this right now, this little guy, and it came to you over Amazon, you just powered it up on 3.3 volts. It's got a full web server running on it. So it's really plug and play. You just start working with it, access the website and kind of build it to suit your needs just from there. Yeah, so if you hadn't seen one before, that's about how small it is. Picture does not depict actual size. I forgot to put that up there. Indoors has a pretty limited range. What wireless doesn't, because you're dealing with a bunch of concrete and steel and here you're dealing with a bunch of water because all the humans walking around, you got about 80% water. That's a lot of attenuation happening. And if you're running, if you're using the wireless chipset the entire time, it's super power hungry. So this, what we ended up learning as we built these is these coin cells running with our code base lasted about 15 minutes, which was awesome. And then it got really, really hot. So if you had little tiny robin eggs, you could crack them on top of the chip and you'd have breakfast for a minute. The other limitation is it's 2.4 gigs only. That's the only band that operates on, which is a limitation for the contest because there's a ton of stuff in the wireless CTF that is on five gigs. So that's just completely out of the ballpark for us. But it makes a really good proof of concept. So if we decide that we can stomach more cost per node, we can upgrade that to a dual band chip and move on. So I want to kind of walk you through a bit of kind of history, lessons learned, or just a journey of the 8266 that we, since we picked this up last year, about December of 2017 is when we started this project so that we could compete last year in the wireless CTF. The 8266 didn't have a lot of documentation online. What it did have was inconsistent between different sources. Even worse, the tooling was just not even there. So development boards didn't really exist for this specific model. Now for the 32, they're all over the place, but this really cheap model, wasn't a lot of resources available to us. So we ended up having to, you know, go back to our electrical engineering days and remind ourselves what a breadboard is. So this was our first kind of development board. The idea was since we were building a network of sensors, we needed at least three. One to act as the root node and two more so we could see how they communicated with each other. So this allowed us to program and run the chips all on the same board, just made it a lot more simple. Even more simple is how you interact with the 8266 flashing firmware, powering it off, putting it into operational mode. Just these two buttons. Well, it's a pull down and a pull up on two of the GPIO pins, but we use these buttons to perform that and a certain pattern of using those puts the chip into program mode so you can take all your, you take your entire program, load it on, flash it, and then it resets automatically and then it's automatically in operational mode. So whatever code you're running, you're seeing it happen right there. So if you're changing the access point, right after it flashes, that access point name is gonna pop up. So it's really quick, a lot of fun. Later on, we improved our design for our development board. This was the next one on the left. We needed them to be individual nodes. We are now ready to go out and deploy these and test them more. So on that board on the right is just a 5 volt FTDI that has a power regulator on it that takes it down to a voltage regulator that takes it down to 3.3 volts. At $3 a piece, they're pretty, I mean, what do you expect? They're dainty. So if you put 3.39 volts into it, they're gonna fry. So it's important that your voltage regulator is sound and we found that this one was really good. And that was 2017. Earlier this year on the right, somebody on Amazon, or somebody released on Amazon their own USB to ESP UART adapter, which I cursed at because I really wanted that at the end of 2017. It would have made things a lot easier. You see there's a switch on the side instead of two buttons. It makes it so much faster, smoother development. And that's $8. That whole thing comes with an ESP 82-66 and the development board. That's why I gave you a link. If you want to get started with this, it honestly just costs you $8. And it's a great way to dive down into the actual beacons and packets and frames that are coming in and out of the 802.11 space. Which, you know, we've competed in the wireless CTF the last two and a half years. We didn't do it this year. And I can't tell you that I ever once actually looked into a packet and pulled out the beacon. I just used tools to do it. So it was really fun to kind of get our hands dirty and really get down to the protocol level quickly, cheaply, and now with a lot more documentation and support out there. So anyways, that's kind of part of the journey. After we were done developing, we had to go back to that requirement of making our nodes, our sensor nodes, concealable. Right, because y'all be thieving. So we needed to make sure you couldn't find them. Or if you did see them, you didn't think they were anything valuable. We even got to the point of talking about putting Cyrillic characters inside of our code in case anybody dumped the firmware. So they thought that, you know, it was coming from somewhere in Eastern Europe. The NSA actually has their own OUI. OUI is the first three bytes of the MAC address for your chip. And so we thought about setting our MAC address to the NSA's OUI, but many talked some sense into me and said that probably wouldn't be a good idea because there might be some legal things that we don't know about. But anyways, it's public. You can go look it up. Just go to an OUI database and type in NSA and it's there. Anyways, I digress. So we needed to build our concealables. So we went from the board you saw and the previous one on the right, which allows us just to take that ESP out and back in to our deployable, as we call them on the left. We upgraded from the nickel cell to lithium-ion batteries. This one is a 3.3 volt. And I think it's a 1200, I don't know what it was in terms of amperage, but it was enough to last longer than 15 minutes. These lasted us about two hours. So we rolled through those batteries pretty quick. But this is just a case. It's a utility case that you might install at your house or something. And we found that with all the heat that was generated, this wasn't a great idea because there's no way to ventilate all the heat so that plastic got really hot. The last thing we wanted to do was cause another fire. Well, we didn't cause a fire, but have another fire at DEF CON. Yes, and these are a little big, right? I had one earlier, but they're about this big, right? About the size of the fish I caught too. All right, so we realized probably not an ideal form factor, so we shrunk it even more. Here's what they look like now. By the way, Todd's acting like he planned all this, but he actually just decided that we were going to start using the coin cells right in the middle of the CTF. Yeah, that was a flexible choice. It was ad hoc. So it's just this little coin cell holder. These were for nodes that we were okay with deploying for 15 minutes, going and picking up and then resetting. I've got a whole box of ESPs here. I don't know if you can see it. If you'd like one, I'm happy to give them away. The ones that we're not using now. So in fact, I've got that whole programming board. I've got an extra one, so come talk to me if you'd like it. And then that is blue masking tape on the battery bank that you see on the left, and it works perfectly. It distributes heat unimaginably. All right, and then we just had Velcro on the bottom, so we would stick these, and I think yep. We stuck these everywhere. We stuck them under tables, behind chairs, behind the pillars on the walls, TVs underneath. We came into the wireless village and stuck them underneath the tables. For purposes we'll explain later. And yeah, so that was kind of our deployment strategy. My goal with this kind of introduction, I'm about to turn the time over to Minnie, was if you hadn't heard of the ESP8266 to kind of give you an introduction to it, it's an awesome little chip. A great way to get started with wireless stuff, either if you just need a wireless access point, or if you want to do some of the more cool things that you can do with the software that you load on that Minnie's going to talk about, and then kind of show you our progress for our methodology and what brought us to the form factor and the deployment that we had here. So at this point, Minnie, I'm going to turn this over to you, and Minnie's going to talk to us about software considerations. So yeah, like Todd was saying, we're just looking for something super straightforward that I could get started with, with a relatively shallow knowledge of wireless and 802.11. I'm not like a wireless expert. I'm sure all of these fine people over here could tell you a lot more than I could. So I was just looking to prototype something really quick, with some open-source software out there that I could fork and just bootstrap in and start writing firmware on the fly. Obviously, I wanted to flash it quick. I had no idea what I was doing with the hardware. If I destroyed it in some manner, I didn't want it to matter. That happened several times, but that's why we work as a team, because I got to build the new hardware that Minnie destroyed. So we used this prototype software at the time called Painless Mesh that a guy named GMag wrote. And basically you have a centralized root, and it dynamically forms a wireless topology based on some kind of shortest path algorithm in the background. And so our leafs are obviously just those little implants out there. And yeah, that was really it. What I'm trying to demonstrate here is that you have to have a root node in order to make this work. So we ended up putting this on just a little Raspberry Pi with an LED screen and carried it around. So for the root node, we ended up getting to a point where we wanted, since they kept sending out foxes to dynamically introduce BSS IDs and have the opportunity to remove them at a later date if we needed to, or clear everything and start over from scratch. So we just took a Python script, hooked it up over serial on our root node and sent it a JSON blob and propagated that blob over the mesh to the slaves. And then we came up with a kind of just a pseudo TCP, SINAC Dataflow, I suppose you could say, just to make sure that the message gets out and that the bots acknowledge the message and that we're actually hunting for the thing that we're looking for or the things, plural. And then, you know, you could probably forward the bot data into like a cool web app or something. But there's only a team of two so we didn't really get to that. But there was another project on GitHub that I got some help from. It's mentioned in the read me somewhere, I can't remember what it's called, but he did some pretty cool visualizations with the wireless traffic for sniffing on just like a single ESP. So for the bots, like I said, going into this, I didn't even know that I couldn't run promiscuous mode at the same time as station AP mode. So I was like, oh, oops, I have to put this into a kind of like a bimodal functionality. So using the task, it's like an asynchronous task schedule where they have saying you write these responsibilities that the bots are supposed to achieve at any given time, like channel hopping or re-onusilization to the mesh network or signal acknowledgments to the other bots. And yeah, that was kind of a learning experience. So we came up with this kind of bimodal functionality in short. And we also found a necessity to kind of change the, when we found a target, we needed to send out an alert and that kind of, with the way the topology changes when the mesh reconnects, we had to kind of change the way that the software is functioning so that the message could get across the mesh network as expediently as possible. So we ended up leveraging some strategies with NTP network time protocol and yeah, keeping everything in synchronization in those bimodal segments at the same time so that each bot was doing the same thing at the same time, if that makes sense. And we'll talk more about that in a second. So this is just the basic duty cycle. So by default 20,000 milliseconds communicating over the mesh, renegotiating topology, getting information about NTP synchronizations and then for nine seconds going into promiscuous and continuously scanning looking for the beacons in the just frames basically 802.11 frames in the air that you're trying to hunt. And then here's the duty cycle where handling communications between the mesh synchronization with NTP obviously with the bots and sending responses to alerts acknowledging that we found a target or not and saving cycles since these things are already so power hungry. And I'm calling this NTP magic because it was all built in a painless mesh and I can't take credit for implementing it. But basically you take the duty cycle time and then you offset that with the current NTP synchronization interval and that basically just allows everything to do what I call synchronized swimming where like we were talking about before they're communicating at the same time and then they're all scanning at the same time so that when someone finds something they can automatically jump into a hey I found your target alert mode screaming at the air and the rest of the mesh continues to do what it's doing and then the message will come over as soon as the rest of the mesh network gets back into synchronization. So this is just a short video. I do apologize. We were trying to get a live demo together and we had some upstream dependency issues that kind of broke. Is that playing Todd? How do you play that? Alright so you gotta give it a sec. So basically on the left and the right we're just monitoring serial of two of these bots and what I want you guys to see is them entering the promiscuous mode at the same time and also communicating by making NTP negotiations. It takes a sec. This is kind of one of the hardest things that we had to wrap our heads around because sometimes there'd be interference where a leaf wouldn't be able to or a bot as we call them wouldn't be able to communicate back to the root node so independently it still needed to be in sync with the rest of the mesh. So the bot initialization it's in mesh communication mode right now and there's actually a lot of back end calls that are happening. The debug level on the painless mesh library to get more granular view of the things that are actually taking place and then there's beacons and it's actually capturing the whole 802.11 frame and we ended up having to capture probe request too because they had a fox where you actually had to capture the source PSS ID of who was making a probe so we had to kind of change our tactics later on and then we had to do a BF for that as well but right now it's just a conditional block looks for a beacon that's in an array of PSS ID targets that you're looking for and then if it doesn't find a beacon it'll check the probe. And so the waterfall of data that you're seeing here just like many was saying is the beacons that we're capturing in sniffing mode and then we do that for 20 seconds and then they go back into mesh communication mode so we have a better name for it. Mesh communication mode works. Awesome. I'll take credit for that. This looks like a duplicate slide. My bad. These are just the JSON blobs the data we're sending back to the root node and then we just put some directional arrows on there to indicate that while we didn't have to do as much walking as we did in the stationary hunt we still had kind of a patrol that we would do so that we had a higher likelihood of being on the move. You can see here that we didn't deploy these all over Caesars. This was a proof of concept for us so the limitation here is that our mesh network would only work for us in the one specific place that we deployed it. This is kind of a map of the hallway right around the wireless CTF from last year and that was an obvious limitation of what we did. And granted you could consolidate nodes and create a distributed C2 strategy if you wanted to. It wouldn't be a huge push up. This is the warp mode I was talking about so basically like I was saying it stops everything it's doing and it just starts screaming at the rest of the network indicating that it's found the target and it does that for a certain amount of time before it receives an acknowledgement from the root and then it also sends back a finish acknowledgement back to the root to tell the root to shut up and get back to its job of listening to as much traffic as possible. And then it re-synchronizes with the same NTP offsets and goes back to its default communication mode with the mesh. Alright. So on the left here this is a bunch of traffic on the root node over Serial. Different connections that we're making wirelessly with our slaves and then on the right I don't know if you guys can see it in the upper right hand corner that's going to be an updater script where we're updating the root over Serial before the root sends out commands to the rest of the bots in the mesh and then on the bottom right I was just using that as an indicator to synchronize the videos because there's another video that's overlaid to give us a sec. We're not great video editors. Don't judge us. Okay, so yes. I sent a target and that's a MAC address right there and that's a real MAC address of one of my devices. Anyways, the root is acknowledging with the JSON blob that it's received it and it's sent it over the mesh. I'm just printing out the JSON on the left there. So now these nodes are actually hunting. Is the there it is? Alright, so we're in a library and as you can see there's one of our nodes connected to a Chromebook and I'm going back to my root next to Spider-Man and we're trying to show you guys here that there's no smoking mirrors and when it catches a target it's going to spit out something in the Python monitor script on the left that's green indicating that it's found one of its targets and we also wrote a script and there it goes and Todd's about I don't know if he's over there like oh what 50 meters away or so? Probably like 50 feet, yeah. And this is pretty basic, you know you just have one slave out there. You probably can't see it from back there but the last number on the right of the highlighted green is the RSSI value it's negative 85. Yeah and now it's negative 78 and so yeah you can also pull that out and go straight into arrow dump so we also had an alpha card and we would just dump that BSSID straight in and start hunting but for demonstration purposes we kept it in monitor mode. Yeah that's when we would switch into just the traditional hunting direction finding but one really neat thing about the way that we deployed these and just I mean it wasn't anything we did it's just the theory behind it is especially with the RSSI values communicating back at that point we can establish direction right so if we're in a hallway and everybody's going that way but our signal is coming back to us saying that hey the signal's getting stronger and each subsequent node is telling us it's right there and we're just looking for the people or person that's just walking towards us and that's when we kind of switch into the traditional mode and get on our feet. Oh there we go so during the CTF we had noticed other people were putting these things this is not ours other people were putting these out in the field for shenanigans like deauthentication we got really frustrated at the end of the hunt because we hadn't found any foxes so we just downloaded what's his name Spacehoon Spacehoon's beacon spamming software and started beaking spamming out the target BSSIDs in and around the village just to drive the other teams crazy yeah so you heard that right we didn't find the fox so I hope we didn't say that at the beginning here's how you find a fox this was just kind of our approach we thought it was cool and novel and we did get very frustrated but we got kind of our we wasted a bunch of some of these guys' time yes it was vindictive for us at least two people went chasing our signal and Mini did something very evil he said a delay in when the beacon would spam so it wouldn't just be constant it would be like every seven seconds you'd get a beacon spam for three seconds it was every 25 seconds it would be for like two seconds you just get a little blip 25 seconds is long enough for you to think that okay I'm going to go out in that hallway and I'm going to go down this way and then before you know it your signal is gone so we watched people and the desperation in their face is they went out into the hallway found it and then it just disappeared and just their face went white well then we targeted that team from Idaho do you remember the gentleman with the white beard at Hunter Tablet we kind of followed him over and then we placed one of them behind the TV we knew one of the goons and he was like losing his mind for good 20 minutes we kind of felt, did we apologize to him? yeah, okay so since we basically came up with this little scheme to have a what I call a Wi-Fi C2 if you will it would be really cool to apply the distributed model to the stuff that's already out there for the SP-82-66 software like the beacon spamming instead of just throwing them out there and beacon spamming to actually have some level of control and feedback D-Auth would be cool too I mean I'm not going to like suggest it to anyone but I'll just say just imagine if you place these outside if someone placed these outside or something like that and just like sat in their car and screwed around with the python script for a couple hours, you could like you could probably, I mean theoretically I'm not suggesting anything to anyone but it'd be kind of fun so for the future we were thinking 802.11 maybe one of the reasons we didn't find the foxes there was like, there's just so much saturation there's so many pineapples and there's so much shenanigans some of the times we could even get like traffic back from the mesh depending on where we deployed it the way that that looked in the spectrum, so like if you were using regular tools like AeroDump what you would see is every 20 seconds an access point would stand up on one of our ESPs and it was called test and production I think so you would see that pop up but folks who were walking around with pineapples that are doing what's called karma mode where they're just responding to every single beacon as if they are a legitimate access point are stealing those handshakes or stealing those initial connection attempts so whenever we would stand up in station AP mode our theory is, we didn't collect the data on this while we were doing it, but our theory is that we would lose connection because our node would try to connect to that karma response so 802.11 really is not a great protocol you know wifi is not a great protocol to backhaul all your communications back to the root node on obviously we're going to use it to sniff and all of this stuff but there's some better options out there, I think we have in terms of reliability I mean for obvious reasons in an environment like this that's so hostile it's just probably not the best choice but it's great for a quick and dirty POC otherwise we're thinking about switching it up to something more expensive that Todd was thinking about yeah well like if we could just stomach more money just walking away with each node if somebody walked away with it then we could do a lot more we could build this into dual band Laura is great for would be our backhaul communications we do that over I forget what frequency it is but we could use Laura for backhaul and obviously you know battery packs and all of that and casings and however we concealed it we could definitely dump more money into it but for us we wanted to keep costs low and be able to test deploy and interact with it pretty quick so in the future if we can do that we might seek out a dual band to do that with but that's it like $30 just starting sometimes more if you know of any please tell us maybe our research is just poor we haven't found it yet but a $3 dual band chip would be ideal yeah yeah we were thinking about just well should we talk about the other idea about clustering the usps together yeah so switching between the modes there's a lot of power and you get all you get there's a lot of overhead too there is things are running on a single thread and you're even though it's asynchronous you know it's just pseudo asynchronous it's basically like coding in the 90s I guess whatever that's like right you're taking up most of that one meg code RAM that one meg RAM is just being eaten up by both of your your processes for going from station mode to sniffing mode so just distribute that over two ESPs and put them in the same box doubles your cost of a node because that's you know two ESPs not a big deal but now you have more processing power available to you yeah and just communicate over serial to you and we could sleep one chip while the other ones monitoring and you save power that way too so yeah definitely but obviously implications with going with the hardware hot spots talking about it we'd have to roll our own code and stop copying other people's stuff which is actually the reason we didn't have a live demo today five days ago somebody committed update to one of the libraries we were dealing with and what we know is we didn't track our dependencies well in the last time that the compiled version worked was May so it's on github and it's MIT so like you guys can take it and do whatever you want with it but all we know is back in May it was working fine yep and so if we had our own painless mesh library obviously we'd be testing any changes there but we rushed into it didn't version stuff and shit broke yeah and just want to tip our hat for all the people who wrote a lot of these lower level libraries for the ESPs and for all the other talkers that did such an awesome job here and for having us thank you guys very much yeah do you guys have any questions oh all right we got two way back there I can't hear you dude just yell the BLE yeah that was an option but cost prohibitive did you say so I'm going to repeat the question make sure I got it right did we think about using BLE for communication across nodes yes cost prohibitive for us because we had to sniff with a wireless chip anyways so putting another chip on there 32 does he says a 32 a 266 is like a stripped down Honda Civic right ESP32 is like an elite Hyundai you know it's not like the best but you do get BLE with it which would be a great idea if I wasn't so cheap I probably would do that great question yes no yeah did we have a linear regulator that right yeah we just plugged it straight in we were like let's go so that may have been part of our power usage issue for sure okay thank you other question up here yeah so the question was if the current constraints of the hardware limited the amount of beacons we were able to parse and the answer was I mean it depends on how fast you're hopping channels and we didn't really have a baseline to measure it against but from what I could tell compared to just standard aero dumps with a alpha card and a laptop it was actually it pulled out a good amount of data yeah we weren't storing the every single beacon correct we were just churning through it and comparing the beacon address I don't know you wrote that logic what did we do yeah yeah we were just looking for the beacon yeah we just compare it if it was the right one then we and the pros eventually yeah any other questions okay thank y'all very much thanks guys