 Hey guys. We're ready for the next talk. It's called Minesh. It's talking from above. I drew a friendly reminder. There's a meeting tonight at 6 o'clock. If you want to follow up with him and ask him more questions. Sounds a really cool project with the drones, especially your drone person. And this is his first time. So please be supportive. And he's really stressed out. But he'll do fine, right guys? All right, man. All right, brah. Thank you, thank you. Okay, so I was a lot more stressed out before actually getting up here, but seeing that a good amount of people actually came to watch, I'm pretty excited. So before I get started, how many of you all are excited to be back here in person? Nice, nice. I like the energy. So that really helps, honestly. A little bit about myself before I get started. Who am I? My name is Sachin, but people usually call me Sach. And I normally tell people I'm just a dude interested in drones and web security. Sort of an odd combo, but it's a bit better explained with a backstory. So let's backtrack a bit. A few years ago I was studying pharmaceutical science in college. And I was complaining to my friend, my roommate one weekend about how I hated organic chemistry. And so he said I should switch to computer science. So I did. And I ended up going on campus one day, wandering around. There's a club, student aerospace initiative. And I just ended up going to the table because they had a model plane. Now they had mentioned they wanted to help programming a simple feedback control system. They'd be using an Arduino to do it. And I had no idea what either of those things were at the time. But it sounded cool. Get to learn how to build a plane. Get to learn how to program it. And maybe even get to fly it. And maybe get good at that. So I said, yeah, I'm down. For sure. Let's do it. And so one week or one day we're working on the project over summer. And I go to the back room, our supply closet to grab some wires. And I noticed there was something in the back. I had never seen something like that before. It looked like it was a drone. But it wasn't really any drone that looked like a DJI drone or anything I'd seen before. So I brought it out and asked my friend who was the club president what it was. And he told me that a dude had built this drone a few years ago. He left it here. So I asked, can we fly it? No. We don't have the receiver or the transmitter. Well, can I take it apart? Try to see if I can figure out how it works? Go for it as long as you can figure out how to put it back together. I don't really think he thought that through because like two minutes earlier I had never seen a drone built like this before. I didn't even know you could build drones. So I'll leave that up to him. That's on him. But within the next few months I started figuring out how to build it. And during that process I was learning a lot of different use cases for drones. They can be used for all sorts of things. So a few of the simple ones were you can use drones to be able to, you can attach agricultural, you can use drones for agricultural purposes. You can attach sprayers, sprayer crops. You can use them for deliveries of all sorts. Medical deliveries. You might be Amazon and just have, want to deliver whatever you might want to deliver. Or you could be the random dude on Twitter whose tweet I saw. The picture on the right is captioned something along the lines of red team photography toolkit. And that got me interested. People use drones for red teaming. I mean is it just for photography? Just for that surveillance reconnaissance? Or do they use them in other ways? What can you do with them? And so I started looking into it and started trying to find some other use cases. And of course one of the most interesting use cases I found along the process was drone racing. So it looks like that's not actually loading right now. But it's an image of someone being able to fly as freely as they want to fly. Because they've built a racing drone. Now a lot of you or some of you have probably seen drone racing before. Some of you may have built your own drones before and may enjoy racing them. And if you have, you probably realize what I mean when I say you can fly truly freely. There's no one there to actually stop you from flying any way you want, anywhere you want. And just enjoying the fact that you're in the air. And so along the road I ended up, well around the same time I ended up finding out what a CTF was. One random weekend I ran across the random Google Beginners CTF challenge. It was a simple web XSS challenge. Probably wouldn't take more than a few minutes today. But back then it took me an entire weekend to figure out how to solve it. And it got me thinking. Like I got some points and was tasked to capture this flag. I actually captured it. And what else could I try to capture? What other flags were out there to capture? And I started thinking, you can probably hack all sorts of things. It can't just be websites, right? There have to be other devices, other applications out there. And so I put two and two together and started thinking, wait a second. Can you actually use drones as a medium for hacking things? Can you use them as a medium for penetration testing? And that ended up bringing me to the question, of course, can they hack the planet? So I started looking for inspiration. And I found a few projects which proved to me that it turns out they actually can. A few examples of those projects are the Danger Drone. How many of you have actually seen Bishop Fox's Danger Drone presentation? I'm kind of curious. Okay, looks like very, very few of you have actually heard about it. So what it basically is, is a drone built using a Raspberry Pi. There's a flight controller hat for the Pi, which contains a lot of the hardware needed to actually have a drone flying, such as like your accelerometer, barometer. And you would attach an external GPS to it. And because of its sheer size, you're able to put any hardware you want on there. You can have a Wi-Fi pineapple, for example. You can plug in any USB device that you want on there to be able to test that RF protocol, for example. And you can also plug in your data stick to be able to SSH into it while it's flying. So you can literally have a flying shell. It's a giant flying shell. Now, there's another project which I found kind of interesting, which was dubbed the Watch Dogs Drone. This one was on hack a day, and it's quite literally just a Wi-Fi pineapple a dude managed to print a 3D case for. And he's attached it to his drone. Now, I don't know about you, but that seems pretty sick to me. You just have a flying Wi-Fi pineapple. You can just fly it around, pretend to be something like Starbucks Wi-Fi and have random people connect to Starbucks and track or intercept all their traffic. Yeah, I kind of want to do that. So while I'm doing all of that, I end up finding out that there's a lot of new regulations which have been starting to, they're starting to be put into effect. And so that brings me to starting to look into them. Now, around the same time, I'm watching a bunch of DEF CON talks, trying to see if anyone has done talks on drones before. And it turns out there's actually a guy back around DEF CON 23 who did a talk called Knocking My Neighbor's Kids Cruddy Drone Offline. I imagine a decent amount of you have watched that one. It was a pretty hilarious talk to me. And that talk, I remember he had a little story about how there was a lot of new regulations, but those regulations weren't really targeted at hobbyists. They're all really targeted at companies and that he had a story, too. A dude came up to him when he was flying and he wanted to know if he was using them for commercial purposes. When I think Robinson or Mitchell, I don't remember their names, honestly, said no. The officer just said, okay, and walked away. And I really, really, really wish that was still the case today because if you're flying a drone and an officer or someone comes to check up why you're flying and you're doing something illegal whatsoever, you can get fine tens of thousands of dollars. So it's important to know a good bit about the regulations in the drone world if you're ever going to be using these things. So for example, in 2015, 2016, a few of the big regulations that started coming out were no fly zones. Areas like airports where you're not allowed to be flying primarily because it could cause interference to the airports, could cause some damage. For example, you were to just lose control of your drone. It was to fail safe and just randomly fly up in the air, hit an airplane. Kind of far fetch, but it's actually possible. Now another regulation that existed back then was a 400 foot ceiling on your drones. You're not supposed to be flying above that. And you need to always make sure that it's within line of sight. And the last one that existed, which I kind of got bothered by, was temporary flight restrictions. So a little story about that. Back in college as well, I was trying to fly one day. There was a football game going on and I'm personally not really interested in football. So I was thinking, hey, I got this DJI Spark for my birthday. Might as well go fly it around this field I usually go to. And when I tried to take off, I just wasn't allowed to take off. All of a sudden this app was telling me that there was a temporary flight restriction because there was a football game and I was within like a five mile radius of it. So I'm thinking like, I really need to learn how to build one of these. I don't want to deal with these regulations from the FAA. And when looking at that talk, I kind of realized why that happened. I had no clue those regulations even existed back in time. So fast forward a few years to 2020, 2021, that regulation landscape has been changing a ton. And there's a lot of new regulations, but namely a few of the important ones are that you have to register all of your aircraft with the FAA. That's not really a big deal in of itself because all you have to do is pay like a $5 fee for each aircraft that you build. And you have to, yeah, you just have to attach a little tag to your drone. So not really a big deal, right? But that was really just the beginning of the new regulations. After that one came out, the FAA started to implement new regulations, including restricted flight relocations, which don't take, they're not in effect until 2022. But what that one is, is that rather than having those no fly zones you had in 2015, 2016, every single place in this country is going to be a no fly zone, except for those designated no, or those designated okay to fly in areas. And I don't know about you, but that's a big no-no to me. So I started thinking how do we get past this? And then another one that I ended up finding while I'm thinking about those is remote identification. Now beginning in 2023, all drones will be, mostly all drones will be required to have remote identification hardware on there. So you would need to be broadcasting all sorts of information, which we'll get into pretty soon. But the main pain point for me was that there's no grandfather clause at all. So even if you buy a DJI Spark, something along those lines, DJI Mavic, any drone that might be older and you're using it for commercial purposes, or even hobbyist purposes, you're not going to be allowed to fly it most likely. My guess is that you're going to end up getting the same type of warning or error message that I ended up getting when I was trying to fly my Spark that day, saying you're not allowed to take off because you don't have that remote ID hardware. So I'm thinking, no thank you. I don't want to deal with this. I'm going to find a way to not have to deal with it. And so I started looking at the FAA website and noticed a few quotes, which were interesting to me. The final rule on remote ID will require most drones operating in the U.S. airspace to have remote ID capability. Remote ID will provide information about drones in flight, such as the identity, location and altitude of the drone that's control station or take off location. So two things over there stand out. First of all, you're sending a lot of telemetry data, which you might be receiving anyways, which it isn't a big problem where your drone is in the air. Potentially important for liability purposes in case you were to ever crash into a drone. But the thing that bothered me here was having to be sending the data about where you are, where you're taking the drone off from. And if anyone ever wanted to come and track you and a really random but and potentially far-fetched situation, imagine if you put your goggles on if you're flying FPV and you're broadcasting this information. Someone wants to receive it randomly because it's most likely going to be accessible over Wi-Fi or Bluetooth, which, I mean, I don't know about you, but I don't know who's going to be sniffing for Bluetooth data when my drone's up 400 feet in the air. But in case someone is, if they wanted to figure out where I am, they could potentially sniff that data, come to me and then do whatever they want while my goggles are on. I can't see them. But, yeah. So that ended up bringing me to reading a little more in-depth into the rules. And something stood out a lot to me. I don't know if something standing out to all of you all, but there's definitely something there. So the final rule on remote ideal require most drones operating in U.S. airspace to have that capability. So most definitely doesn't mean that every single drone that we build would have to adhere to those regulations. So how do we get around that? And it turns out, as I'm reading through that website, all drone pilots required to register that their UAS must operate their aircraft in accordance with that final rule. Now, that means that if you have to register your aircraft, you have to adhere to all these new regulations. When do you have to register your aircraft? Does everyone have to do that? And once again, it turns out you don't. Which meant, oh, yeah. Which there's a solution to. I will get to that pretty soon. But so I started experimenting and ended up building the drone that you see over here. And there's a few different things which I ended up learning from this process. So you really only need a few components to be able to build a drone which are able to communicate with your ground control station or to be able to talk to any software that you might write. Now, those devices are a telemetry system, meaning that you can have an arbitrary radio system to communicate. And you need to have basic components such as an accelerometer, barometer, GPS. And when you're actually transmitting that data back and forth, you're doing so over some arbitrary radio link using a multitude of protocols. Now, while doing so, I realized that there's actually a lot of different flight control softwares that are used in the drone world, such as Betaflight, INAV, ArduPilot. And ArduPilot's the one that was most interesting to me because it used a protocol called MavLink to send all that telemetry data back and forth. Now, that brings us right into the solution to the problem I had earlier. We have to figure out a way to build a drone utilizing some flight control software which is able to send us telemetry data. And the only way that we can do that and to circumvent those regulations is to be able to build a drone that weighs less than 250 grams because that's the only type of drone or the, those are the only drones that don't actually have to be registered and don't have to be retrofitted with that remote ID hardware. So I set out to figure out how to do that. And the first drone that you see over here is the very first prototype of what ended up being called Valkyrie. And yeah, that's the first prototype of a drone that I call Valkyrie. And it's designed exactly to be able to use a remote or it's designed to be able to use the MavLink protocol to communicate with the Raspberry Pi and allow me to actually remotely control that Raspberry Pi all while being light enough to be able to fly so that I don't have to deal with any regulations, don't have to pay for any extra hardware and really just don't have to have any potential interference one on the drone with anything I might be wanting to test. Let's say I wanted to be conducting some Wi-Fi attacks. If I have the remote ID hardware and it ends up transmitting data over Wi-Fi, that might end up causing some problems. And a few other things that might end up leading to problems, but we'll get into that a bit later. So a few comparisons between the drones that I've seen in the past and the project that I ended up starting. So the dangerous drone, for example, you can see it's pretty large, right? Its propellers look like they very well could be, they very well could be larger than the size of this thing. It's like the size of my face, if not even slightly smaller than the size of my face. And if you were to ever fly that and you were to ever crash, you were to ever to lose control, if someone randomly decided to jam your GPS signal, your running flight software that requires you to have stabilization in GPS and your drone fail safes, you're going to cause some damage to everything and everyone around you. And that's not really the only issue associated with it, but here's the little image of the frame that the dangerous drone was built with compared to the size of this drone. That's one arm on the dangerous drone and the entirety of falcury sitting on top of the arm. Like, this isn't going to hurt anyone if it ends up hitting you because I actually ended up modifying the wrong parameter, toggling the wrong zero to a one, and this thing flew straight back into my chest and it left like a little cutter too. It's not that big of a deal if it ends up hitting you and even if it does, you'll be perfectly fine. I mean, I'm still here. I'm giving this talk. So now the next one was the Watch Dogs drone, which I was also really interested in. People are using drones to be able to have rogue access points flying in the air. Like I mentioned earlier, you can literally be Starbucks Wi-Fi if you want to be Starbucks Wi-Fi. And you can fly your drone around anywhere you want. Fly it to a Starbucks for all I care. But there's a problem that I thought of. If you actually want to be within those, that weight limit, you would likely end up having a lot of problems in terms of the hardware you can fit on the drone, the types of motors, the types of battery life you can fit on there. And there's a lot of other issues, which you can, yeah, there are a lot of other issues. But you end up not being able to control that Wi-Fi pineapple. You end up not being able to actually control that drone and being able to access any computer that's on there unless you want to add that extra hardware, which was really my only issue with this because I thought it was honestly a super cool project being able to just fly around as a rogue access point. So I ended up looking into how you actually can send telemetry data back and forth and realize that if you're using software like ArduPilot, which from the videos that the danger turn had on it, it looked like it was actually flying with ArduPilot, you can send a lot of arbitrary data over this protocol called Mavelink. And so let's learn a little bit about the basics of the Mavelink protocol. So in general, it's a lightweight messaging protocol for communicating the drones and those components onboard drones. That's according to the docs. And for example, if you have a camera which is able to speak Mavelink and your flight controller speaks Mavelink, you can send all that data back and forth and you don't need to really have any special firmware on either of those devices for them to be able to communicate with each other because you're encapsulating it all in Mavelink. And when I started looking into that, I realized that there's a lot of different messages, message types, which you can actually utilize to send all sorts of different information. There's information like GPS data, RC data. There's a lot of status text information, which you'll get when you're sending basic connectivity issue information. You get a lot of parameters sent, which is all just plain text strings all over Mavelink. And so I started looking into how I can actually utilize that, how it's actually transmitted and how it's received. And you can use just an arbitrary radio link. You can use anything that you might use when you're racing drones, such as the crossfire receiver system. You can use Dragon Link, the RFT-900 devices, and tons and tons of other devices. You can transmit the data over Wi-Fi and the list is really endless. So when I started digging into all of that, I started wondering how do you really establish a connection with this drone? What does that really even look like? What does that even mean? Because people have ground control stations, but what is that ground control station really even doing? And so I started digging into it and I realized that there really isn't just one answer to that question that is entirely dependent on the ground control station software that you're using. But there is one thing which always remains consistent. And what that thing is, is that you have to be always transmitting heart beats back and forth between the quad, which I'm going to start calling a MAV now, by the way, because MAV link, that's what it's identified as. So between your MAV and your ground control station, your ground control station can do all sorts of different things, such as requesting a data stream whenever you start instantiating that connection and you'll get tons of data like parameter data. But as long as you are consistently sending those heart beats back and forth, you will have a connection established. So here's an example of one ground control station, which is actually the most popular ground control station that people use when building these drones by themselves. And it's called Mission Planner. So when you start up and you're trying to connect to Mission Planner, there's a long FTP sequence, but it's not just an ordinary FTP stream. It's rather, in case you're encapsulated in MAV link. So a special little protocol to be able to transfer specific data back and forth over MAV link. And I noticed that it ended up causing a lot of connections to hang. That could be partly because of the fact that the receiver that you're using doesn't have enough bandwidth to actually support sending all of the data, all those parameters back and forth. But it also could be because of the fact that your, it could also be because of the fact that your MAV is just getting too much, eh, stress. Oh well. I'm going to go past that. So the device that I have on board ended up having the problem I was just getting into on the last slide. And it's called TBS Crossfire. I had mentioned that you use it when you're racing drones a lot of the time because it's a low latency link. It has really long range and it has a low chance of fail safe. So I had been using this thing and was wondering how can I actually take advantage of this to be able to work on this project I want to work on. And I discovered that in the past few months they had started to add MAV link bridging functionality and you could use the Crossfire receiver to be able to actually send MAV link data back and forth. You can forward it over to any device that you have on your network because the Crossfire system has a, it has a ESP8266 I think in it and that means that you're able to actually create a little soft access point which you can connect your whatever device you want to to be able to receive the MAV link telemetry. And so I was wondering how can I actually use this to get MAV link data. Because now I've realized that MAV link data can send any arbitrary information that I wanted to and now I've realized that my drone can probably stabilize itself so I'm getting to the point where I'm wondering how can I have this thing just hover somewhere and to be able to send data back and forth. And so I start taking a look into what the Crossfire connection looks like and it turns out that there's a few options within Crossfire which you will need to kind of understand to be able to actually take advantage of it fully. You can transmit MAV link telemetry over it but if you are to try to actually have your RC packet sent over MAV link then your telemetry system ends up getting a lot of the bandwidth ends up being hogged up so you aren't able to send a lot of the telemetry data that you see. Like you can see there's mostly just radio status messages so I ended up trying to figure out how can I end up sending any random messages that I want. How can I use this more precisely to send specific information back and forth to for example a Raspberry Pi that I ended up putting on here. And I end up having to dig into a lot of different MAV link messages to do that because like you've seen there's some radio status messages, there's file transfer protocol messages but these don't seem like there really any standard messages. It's all data just being sent over MAV link and once again you can send really whatever data you want as long as you can modify that protocol in some way. So to do that I started digging into what the MAV link frames ended up looking like and there's a few important components here which are really unique to just MAV link and those are the system ID field, the component ID field, the message ID and the payload data fields. Now if you take a look at the system ID that's just the idea of a system sending data not an idea of system receiving it, similar with the component ID and then message ID. All of those are really just used to route data back and forth between different components on your MAV and then also used to decode all the data by the MAV link system and then the payload data was the interesting part. Message data, content depends on message type. So if you can send any arbitrary data that seems like it would be pretty useful for a start, right? We might be able to craft some special protocol on top of MAV link to be able to send data to a specific component on our device. For example that Raspberry Pi. Yeah. And so another thing that stood out to me there was that there's no, it doesn't seem like there's really any way to ensure that the message that you receive is actually being sent from a component you intend to receive it from. So I'm thinking that and a few months after I had that thought there ended up being a CVE for MAV link and if you were to send something like a change operator control message for example you would be able to actually try to take over the connection. So for example if you had a MAV link network and this drone had a target ID or it has a system ID of one and a component ID of one and I'm just a random dude sniffing that connection because it's being transmitted over some random open Wi-Fi network then I would be able to forge packets to be able to tell that drone that I want to change the operator to my own or to myself and I want to have that drone come and land to me. That was a thought that I had and then I realized that it's actually a real vulnerability because some dude got awarded the CVE. Kind of wish I knew a little bit more, a little bit more about MAV link back then but oh well. So that's the key difference between MAV link and MAV link too. There's that extra signature field which allows you to actually sign all of the packets and if the MAV doesn't have the packet signed by the right key then it won't respond to just those command packets but that means that you're still able to receive all the telemetry data and to send certain telemetry commands back and forth to it. So I started digging in more and realized that when I'm trying to generate new commands there's a lot of unknown messages and that ended up being because there's multiple dialects that you can use. So if I want to be able to build this drone which is using some telemetry system and I want to have that telemetry data forwarded and over MAV link then I need to make sure that any system that I build is going to understand every message, right? So I don't really want it to be dependent on any type of flight control software. I don't want it to be dependent on the flight control dialect which ends up being why some of the messages I was generating weren't really understood because there's a lot of different dialects and this software is using RD pilot so there's an RD pilot dialect which ends up being a big problem for me for a little bit and then, yeah, that was a problem for a little bit but I started digging into some of the different messages, message types and trying to figure out how I can actually get that telemetry data forwarded after I started trying to mess around with different messages and realized there's a lot of actually different message types but there's only two that are really important for having the pi route all the data back and forth. So there's broadcast messages which the most important of which is the heartbeat message. Now any time you are trying to establish a connection, like I mentioned earlier, you need to be making sure that a heartbeat is being sent back and forth constantly because otherwise your MAV is going to fail safe and that could mean a lot of different things. It could mean it just drops out of the air. It could mean that it ends up just returning to home if you've configured it properly and it could also mean that it will try to fly up a few hundred feet in the air and then end up hitting a tree and doing some stupid stuff. But the heartbeat message is used for a bit more than just that because the heartbeat message, when you initially create that connection, you have a few parameters which you won't actually see on this slide but the system ID and the component ID from which a heartbeat is being sent from need to be, they need to be processed by any component that's receiving maveling data. So that ends up, you end up seeing that over here. So on the top half of the packet or the frame, you end up seeing the system ID on the left, a system ID of one and a component ID of one and that usually will end up meaning that that's your MAV, that's your drone sending that data and you are, you can see that also from the type that second field indicates that you are a quadcopter, then the autopilot three value means that it's RDPilot and the base mode of 81, that base mode of 81, I actually think I ended up just adding a random field up there. So that isn't one that you would often see but why that's important is because when your ground control station is sending data back and forth, you won't ever actually see a base mode value other than zero. So that's how you can kind of determine whether or not it's a ground control station and if you think about the CVE that was present in MAVLink one, if you ever see that there's a MAVLink version of one, then you can determine that or you can determine whether or not you have a ground control station, whether or not you have a MAV and then you could potentially use that to craft a packet to be able to try to take over that drone. That's not something that I have really experimented with too much but in theory that is exactly how it works. So you see that on the right as well. The type of six means that it is an RDPilot ground control station I think and then autopilot eight means it is an autopilot invalid. So yeah, that's how I tell the least when it's a ground control station versus MAV. One second. Dehydrated. I don't think this will help too much. Okay. One on a bit longer than I should have already but so we'll get into point to point messages. Basically there's a target system, target component field in your message which indicates what device you're trying to talk to and you need to have that device be able to interpret the message. For example, the Raspberry Pi at least in my project has a target system field of one, target component field 191 and so anytime that I'm trying to send messages to it as long as those two parameters are present in the message then those will be routed to the Raspberry Pi through the flight controller and that's all handled by Mavelink routing which we'll get to pretty soon. It needs to go through the networks pretty fast but Mavelink networks are generally composed of a system and each system has components. Now systems have a system ID to uniquely identify them and systems can be things like drones, ground control stations. Those are generally the most common ones. Those each have their own components which also you need to have unique values. Now an example of a basic network, so let's say the network ID is zero and you have a system ID of one. If you have a flight controller and a Raspberry Pi on board like this one you would likely just have a component ID of one, component ID of some arbitrary number you could decide but generally Mavelink docs say that you should have 193 for your, yeah you should have it set to 193 for a companion computer. Now your ground control station is going to have a system ID of 255 and component ID of one and that's only really important because you need a way to actually make sure that the flight controller is able to process all of that data, all of the Mavelink packets and to be able to route it to the proper component and so let's take a look at a slightly different network. Now you have two different telemetry end points on the system rather than just having that singular component ID of one you have a component ID of one and two but what if you wanted to set up a network with a component ID of one and you have another telemetry end point which tries to connect with a component ID of one as well. Well it's not really going to work and there's a pretty simple reason for why that's the case but that gets us into Mavelink routing. So back to the initial image but this time take a look at the system ID and component ID fields. When you're trying to send those messages as you saw with the point to point messages those messages and those fields are being processed by the flight controller. There's a lot of rules which actually govern how Mavelink messages are routed but at a very high level. For example if you send a message with a system ID of zero it's a broadcast message. If you send a component ID of zero in your message then it's a broadcast to every different component on that system and so you can utilize that to be able to actually target messages specifically the different components on board. So I don't want every single message to be processed by the pie. I just want to be looking for very specific messages if I want to be modding this protocol. Now I'm probably going to have to skip through this part but that ends up bringing me to a question. Why do I end up needing to create a new protocol on top to be able to control this pie? That brings us into the alternative. So that alternative is the serial control message which already exists. And that's your little control message is generally used to be able to modify hardware devices. You can forward Mavelink data over any network. You can use things like mission planners, Mavelink forwarding feature which allows you to create a little server which has Mavelink data and it's transmitting that data back and forth through or it's all being encapsulated in Mavelink and I use that to modify GPS which I would likely need a good amount of special hardware to do so otherwise. And I started testing that message to see if we could actually use it to send data back and forth to the pie. But we, I ended up realizing that I probably couldn't. So while I'm testing it I realize there's a buffer size of about 70 bytes per packet which we can work with. And I wonder what happens if we send more than that. So there's still only three packets being transmitted and they're all the same length. Which makes sense when you're taking a look at what the actual message structure is. But there's a few problems associated with using that. And it's funny because I asked the developers like why can, like why do you not really support the use of having a shell in the air? And they said I mean why would anyone really ever want to have a shell that can fly? I'm thinking there's a lot of reasons why people would want to be able to have that. But I guess they didn't believe the same thing. So I ended up having to dig into a bit more and realize that there's no chunking mechanism. So that's dependent entirely on your ground control station. If you did have that chunking mechanism then you would see a lot more than those three serial control packets which I didn't see when I'm looking at the packet capture. So I started looking into if there's no chunking mechanism then is there at least a way for this maveling data to be routed to the proper component? And it turns out that there really isn't either because there is a enum in there which says that, which you look for, the serial control device. And there's a serial control dev shell which was the only promising option that I could use. But it's really not promising because the RDPI of the devs completely stopped supporting this. So by this point I'm thinking I don't really seem to have a way to take advantage of anything that is already built into RDPilot. Mavelink doesn't really have any messages that I can utilize. So how do I actually go about controlling this pie? So the choices are to modify really everything related to the serial control message that already exists in the RDPilot and the Mavelink repositories or to create a new little protocol and system on top of it which doesn't rely on anything other than the fact that your device is able to actually speak Mavelink and you can route that telemetry properly. So I didn't want to end up like the first guy. And so of course I end up choosing option two and I end up creating something called, or what I call MAVSH. So what that is, is components of a few different software components. There's DRDPilot flight controller software which is on board and you can use any flight controller software you want as long as it can route Mavelink packets properly. And the Mavelink protocol modifications which we'll get into pretty soon. And then a ground control station. So quick caveat on that. That ground control station mod didn't end up seeming to be too useful because of some of the bandwidth issues I noticed with Crossfire but the TLDR is that all of this together enables you to actually access the Raspberry Pi's shell on here without having to use any 4G, LTE, any cellular networks, any Wi-Fi, et cetera. And so you're able to actually control the Pi without having to do any of that. Meaning you have less weight on your quad. Meaning you can fly it wherever you want and you don't have to add remote ID and no one can really track where you're trying to fly. You can do whatever you want with it without anyone really even trying to track you and they wouldn't have a good way of doing so because you don't have to deal with any of their regulations. So here's a pretty high level overview of how the protocol works. So you'll send a Mavis H init packet and then the quad will be listening for that. Rather, the software on the Pi will be listening for that. It validates the message origin to determine whether or not it actually should be receiving init packets from that. And then once you validate that origin you'll reply with an AC packet containing information about whether or not the session was accepted, whether it was denied. And if it's accepted then you wait for a SINAC to come there. You send a SINAC and then wait for another one which I know kind of counterintuitive but yeah that's the order I ended up going with just because. And so once you receive that second one you're particularly listening for that second one just because when you're near the edge of a telemetry range you're often losing a lot of packets and I personally just noticed that there didn't seem to be a really good way of handling that issue and since the project's pretty early in the development I'm hoping to find a better solution to it but for now we're just sending another packet back. And once that session is established you're sending a Mavis H exec packet which contains some arbitrary payload that you want. For example if I wanted to run an end map scan or if I wanted to connect to a random network using the Pi on board then I could do so by sending that encapsulated with the Mavis H exec. And whenever I receive the exec call from the Raspberry Pi I'm running some sub-process calls which once the output's complete it's chunked and then transmitted as Mavis H responses and whenever it's completed and the ground control station has received all those packets you will or you just reset the state for the process to be ready to transmit. So simple picture of the proof of concept being born the very first time that I actually got it working and you can kind of see that the heart beats are being sent the syntax are being sent and then whenever all that is done the sessions considered accepted and you can start actually utilizing that telemetry link to send to send any commands arbitrary commands that you want to be run. So that is the proof of concept. Since I'm running long time I can't really go through the build process but that's all going to be up on rotor builds and probably on github as well. I need to get an actual public repository open so that will be dealt with in a bit but here's some just general images I'm going to quickly go through of the build process gathering everything together and eventually getting something pretty similar to this so quick demo. We got to go to YouTube so laptop on. Please full screen. One second. Okay so to the Wi-Fi network that yeah running around here I don't know what it's called. That is loud. Okay I'm just going to talk over it instead. So the goal here is to have the drone I've just set up a simple like two simple tables and my goal is to be able to have the drone fly over towards that table. I'm pretending it's the roof of some building and I have a simple open or I have an open hotspot. The hotspot's named Starbucks Wi-Fi just because it's pretty common so I want to have the drone be able to go fly over there land on top of that quote-unquote building and have it connect to Starbucks Wi-Fi and once I do that I want to see if I can randomly scan the network see if there's any vulnerable devices on that network and that's all being done over the telemetry link so I don't actually have to have that extra hardware those extra Wi-Fi adapters on board to be able to have all of this work because once again I don't I really don't want to deal with those regulations less than 250 grams as light as possible as long of a battery flight or as long of a flight as possible and yeah that's the goal that will always be the goal and getting it smaller is always the goal so right now it's arming up I think see can we hear the Imperial March yeah oh answering my own question it's the one time where I'm kind of happy that I've heard recorded this part flying this thing indoors would not be a very good idea by the way it's going to be taking off now and the stabilization functionality on the software is decent but since I don't want my goggles on I kind of suck at flying without being fpv you're going to see it just wandering around and the goal is to be able to land on that table so let's fast forward just a little bit and you'll have to believe me that I actually managed to land on the table so what's going on in the background now there's a network like I mentioned Crossfire is actually able to bridge Mavelink telemetry over the built-in ESP 8266 and so I'm connecting to that I want to be receiving that telemetry and so the program that I wrote is actually establishing that connection all over Mavelink and here's just a quick here's just a quick little bit of proof that the middle T-Mux pane is actually the Raspberry Pi the very bottom T-Mux pane is my laptop it's connected to a completely different network so the Raspberry Pi is currently now connected to the Starbucks Wi-Fi and let's keep going so yeah two or three minutes okay simple service scan on the network I'll skip through a bit of this takes a little bit of time actually but I start to see something that's interesting there's a little system on the network which I mean port 139, port 445 are open, Windows 7 through 10 potentially it's a simple end map scan I don't end up doing too much enumeration because well it takes some time and my battery is kind of low at them at the time so for the sake of the demo you're just going to have to assume that the system was vulnerable to eternal bloop yeah fast forward a little bit more just me going through okay and so I have a simple reg set up a cloud VM listening for this reverse shell that I'm trying to get and in a second you'll probably see that we do end up using the maveling session to be able to run that exploit and the moment is pops up you'll see that the cloud VM that I had was running its listener and it ended up getting a reverse shell connection back from the Windows machine which once again vulnerable to eternal blue so not that really not really that hard to pop the shell but nonetheless it's all being transmitted over maveling and it ended up working so the project's pretty early in its stages so if anyone's really interested in working on this with me if anyone found it interesting the concept of using maveling to access a shell hit me up and yeah I kind of want some people to work on it with so thanks