Hello, everyone. I am Vaishanath Achyat from Texas Instruments and I would like to talk to you today about using Graebers for robotics and real-time applications using Sepharatos. I work with the Texas Instruments Linux development team and TI has a strong history of open source collaboration and contribution and we plan for long-term sustainable products with an open source ecosystem in mind from the device architecture phase itself. And we also focus on an upstream-first methodology in our internal and external development as well. As part of my day job, I work primarily on Linux kernel and UPUT for TI devices and I also maintain the TI devices in the Sepharatos. I was introduced to Graebers and Sepharatos through a Google Summer of Code project with Bigelboard.org in 2018, where I worked on enabling support for these micro bus add-on boards in Linux. So micro bus add-on boards are these plug-in boards that goes to micro bus sockets. So this is how I have planned the talk. We'll just go through an introduction to Graebers. Then developments on using Graebers for IoT, then BigelConnect and some limitations and how I have a proof-of-concept to overcome these limitations. And then I also have a short demo where I have something, a real-time control loop running through Graebers. So what is Graebers? So Graebers is an application layer protocol which was developed as part of the modular smartphone project from Google called the Project ARRA. So this was not released to market. So the concept of this modular smartphone was that you will have a base module smartphone which will have some basic features like your processor and all basic features. It will have expansion connectors on which you can plug in different modules to it and create your own customized smartphone according to what you want. So if you want a higher resolution camera, you can plug it in, you get the camera. If you want a projector on your smartphone, you plug it in, you get that. So unfortunately Project ARRA smartphones did not reach the market, but something similar the Motorola Moto Modes actually was released to the market. It uses similar concept. So we plug in modules and we have your own customized smartphone. So how does this work? Yes, you just plug in a module and it just appears on your Android phone magically. So the underlying main subsystem that is there is the Graebus subsystem in the Linux kernel. So Graebus, you can think of Graebus like a remote procedure called application layer where the host can control and discover modules that are connected. So if you connect the camera module, the host that's the base module can detect what's connected on it through the Graebus manifest-based identifier mechanism. It can also send and send commands to this module, get operations done, then get back results to the host. So what's different? So it's just an RPC protocol.  So the main thing, the beautiful thing about Graebus is that Graebus has strong ties within the Linux kernel, different multiple subsystems, and also Graebus has a well-defined module identifier mechanism through which we can describe and discover the add-on modules connected. So if you look at Graebus and the Graebus underlying code in the Linux kernel, you can see that multiple different peripherals or the buses have equivalent Graebus virtual representations in the kernel. So if you look at I2C, UART, SPY, USB, power management, PWM, camera, audio display, all those things have a virtual equivalent of Graebus in the Linux kernel. So with Graebus, what you can do is that like, let's say you have your, let's consider your modular smartphone, that runs Linux or Android, and you have your module, let's say it's a module that has a GPIO expander, or let's say it has an I2C bus. You plug it in and through the Graebus discovery mechanism and it's actually appearing on the host as an actual bus. So you are mirroring and a peripheral on the add-on module to the host Linux system. So the main concept, concept behind Graebus is that to keep all the most of the intelligence within the host system, and these interchangeable modules can create your own unique kind of systems. And these remote devices, the add-on devices always run some generic firmware. It does not have, so let's say, it does not have any custom firmware, it's more of a generic firmware. And here I would like to talk about some advancements in Graebus for IoT. So Graebus for IoT was first proposed by Alexandre and he wrote the base framework for using Graebus and then Chris who is a sufferer maintainer who he took up the he ported the, originally the Graebus device site firmware was in the Natex RTOS and Chris ported the Graebus subsystem as a sufferer module which has, so then now we have the platform code and the application code loosely coupled and any platform that supports sufferer can also use Graebus for sufferer. So, and the primary transport being implemented is TCP IP because you can send TCP IP or anything and there are also other transport supported. So, and there is also user space applications written by Alexandre, it's G-bridge, so you can think of it as a bridge between your Linux kernel and your remote device. So in the actual project era or the motor modes these modules were directly connected to the smartphone or module and it was talking through a transport called UniPro which is a standard in the process communication protocol from IP. So now the, but the Graebus being an application layer there is no strict requirement that we should use it, the XR transport we can use any transport, so we are just passing the messages through the transport. So, what actually happens with this Graebus for sufferer module G-bridge and this ecosystem is that, so we have a remote node that's around sufferer and we have the sufferer, Graebus for sufferer module works on it. Now what happens is, so let's say there is a GPIO chip on that remote module microcontroller, so that GPIO chip is getting mirrored to your host system through the Graebus and the all the underlying maybe the complexity of the RPC layer is abstracted away from the user. The user just sees a standard GPIO chip on the Linux system like it was actually physically present on the particular host. So now let's say I use, like I try to toggle this GPIO. I use some libgp, GPOD standard commands and toggle this GPIO. So this is a standard GPIO chip interface in the kernel, but it's exposed by the Graebus GPIO driver, then it goes to the Graebus core, it creates an operation, it goes to the G-bridge and it goes to the remote node. So it, how it goes to the remote node can be any transport, it can be wireless, it can be wired, it can be UART or anything, so on all my demos from now I am planning to use the 802.15 for sub G, low power wireless as a transport. And now it reaches the packet, reaches the suffer node, it goes to the RX handler, then Graebus handler, then it goes to the suffer standard GPIO call. So that's how a GPIO works. It's not only GPIO that's supported, earlier we saw what all peripherals or subsystems had equivalent Graebus versions. All those are supported. For the interest of suffer, Graebus for suffer or IoT, we are just focusing on spy, I2C, GPIO kind of process. So I'd only like the right now we can use Graebus for IoT and like I would like to introduce you to BeagleConnect and BeagleConnect Freedom. BeagleConnect is a revolutionary technology from BeagleBoard.org, which uses this Graebus for IoT and device drivers in Linux kernel to virtually eliminate any low-level software development. So earlier we saw that GPIOs on a remote microcontroller appears on the host as if it was already on the host. Now we can have I2C devices or spy devices appear on the host in similar manner. Now think of it in the next level. So you have a device on the I2C bus. So now it seems the I2C bus appears as if it was on the host. You have that device also appearing on the host. So what you can do is you can reuse the existing device drivers in the Linux kernel to work with the sensors and actuators and devices that's connected on your remote microcontroller through Graebus. And so now we are using the Graebus for IoT with the G-bridge and different utilities. We are not tired to be using any project or a specific hardware or anything. Your host can be any Linux host. It can be your laptop. In my cases I am using a BeaglePlay development board, which is one of the newest single board computers from BeagleBoard.org. I am using that as a gateway and it talks to the BeagleConnect freedom, which is a wireless MCU from BeagleBoard.org and it talks our low-power sub-gigahertz 802.154G. So now what I have is a small demo. So I have this BeaglePlay running the stock Debian image from BeagleBoard.org and I have the BeagleConnect freedom connected on a separate room far away from this gateway. So now what I am doing is this there is a script called Start BeagleConnectGateway. So it just sets up the network and pings this remote node. Then also starts the services like G-bridge. So now what you can see is it's the host system. It's running Linux. This system is running Safari. This is far away and I am logging into the host BeaglePlay. So in the kernel logs, you can see a light sensor and a humidity sensor popped up. So it was not ever actually connected to this system, but it was actually here. So this light sensor appeared on the host. I can use standard Linux utilities like IAO info or any other higher-level middleware utilities to get the sensor readings, make measurements and all. And I did not even have to know that what sensor was connected or even the register map of this particular sensor because all the drivers are we are using from the Linux kernel. And also in Linux, almost everything is a file. So reading sensors, reading, controlling actuators, all just is simplified as simple file operations and you don't need to do any lower-level development. So this I showed for the light sensor and the humidity sensor that's on this board. You can even add on all these microbus add-on boards and make it work with the same system. We have tested with around 150 add-on boards. You can have just plug-and-play support and make it appear on the early Linux host through Gravers. Maybe I'll stop a bit if you have any questions regarding how like this is the state of Gravers for IoT and we will connect now. Okay, so right like earlier what happened during like the sensor reads and all was that so we have a light sensor that works through like I2C. So it needs some I2C transactions to set up like trigger the measurement then get back the measurement. So through Gravers, we were sending all these transactions and like continuously making all these measurements. So one failure, one this can really simplify a lot of IoT applications where you don't want to do lower-level development, but you want to focus on your middleware or your actual application and you just want to prototype different sensors. You want to try out different systems and you are more interested in your final application more than getting any particular sensor work on any different particular board. So I experimented with the Bigel Connect Freedom and Gravers for IoT and a few things I find was that so in the project are a smartphone the host module and you are actually physically plugging it into the add-on modules to the actual smartphone. So there is so the and the purpose like and the functionality is only useful when the host is active. So in IoT applications, your central gateway or the node is sending the commands to the remote node, but even if the gateway goes down, you might want to have some operations happening in your remote nodes. Let's say for example, you are deploying a weather monitor or an air quality monitor. So you are continuously pulling this data from the sensor, but let's say your host goes down or the connectivity between your host and the remote is not working. Then your complete system kind of goes down, but let's say what if you could have off-load to the remote node, it compute the average sensor readings continuously for a day and your host will go and read back the sensor reading after a day or once per day and in the previous case, you are continuously pulling, so you are continuously sending Gravers operations to read all these I2C transactions and making the readings. So it's also not very power efficient in some use cases. So if you could off-load to do it something like let's say take a reading, then wait for a time or like maybe suspend, wait for a time or wake up, then make the reading and do average. So you could optimize it for some use cases where power is also critical. And we can so in the project-array use cases, the transport was very, the continuous, reliable and very high-speed transport. In IoT use cases, we could have low data rate transports like the sub-gibbards, long-range communications. So before how we could just like make some changes to overcome these limitations, I would just like to talk about how a Gravers operation looks like. So I'm not going into the details of Gravers setup and also one of these operations, you can think of each Gravers transaction as an operation and all these operations will have a short header than a variable length payload. So this payload will be depending on particular operation. So let's say you in the earlier case, we talked about toggling a GPIO. So how the Gravers operation packet for the toggling a GPIO looks like is we have an operation header. It has fields like size, ID, then there is a field, important field type. So with the field type is how the particular handler is being called. So if the type is the if the type is GPIO set value, then the GPIO set value handler at the remote node is called. There is also concepts of C ports, but for simplicity, we are just talking about how the handler is involved. And the payload is actually specific to each transaction. So for this particular GPIO set value, you'll have a payload saying which and value. It's the offset on the GPIO chip and what's the value to set the GPIO to. So one of the difficulties I face during this prototyping or working with Gravers is that Gravers has a complex stack starting from your Linux kernel, then netlink to the user space, then the user space application that bridging to the remote node. And you need to have a Gravers for software remote node functional to do any prototyping. So I wanted to isolate some parts of the system and test few parts. So I kind of combined the Gravers kernel functionality and GBIT functionality into a small Python library. It does not implement all the functions, but only few of them functionality that's of interest. And with this, what you can do is suffer has a native POSIX target. You can do CI and testing or you can do prototyping on your host itself.  So here is a proof-of-concept I have for overcoming some limitations we discussed regarding using Gravers with kind of slow or unreliable transports. So we can just send transaction Gravers operations one by one and execute at the host together. So we can do some let's say you have a sensor which has something like an enabled GPIO, then you enable the sensor using a GPIO toggle, you read the data over I2C, then you disable it. So maybe you can combine all these send one by one and ask the remote node to maybe execute it together. But this kind of approach is not useful in most cases because you need to have some decision-making capability at your remote node. So what I have added is that you had allocated some scratch pad kind of registers or you can say it can be considered as temporary variable, a temporary memory region where the host can write constants, read back the values, and also the host can perform arithmetic operations on this scratch pad. So all these are new Gravers operations I have added. So you can read to this register region, you can use this as a temporary holding register variable, read, write, and also do perform arithmetic. You can do a few more things. You can do make another Gravers operations payload to this scratch pad or use this scratch pad region as the payload for another operation. For example, you read an I2C sensor data using let's say I2C read word, you get the sensor data, you can actually put it to the scratch pad region for further processing. Then we need some decision-making and nitrating operations. So I added two operations for if and while all this takes the input conditions or operands from the scratch pad region. So you can do like if scratch pad register five is true, then perform some operations or while scratch pad register is true, you can do some operations. Then also a simple playback option where you can combine all these previous building blocks, you can kind of put a sequence together, send it, you can play it together, or you can even ask to play it indefinitely as well. So this is the operation. So one deviation I made from the Gravers specs or the existing Gravers operations is that so far all the Gravers operations have a short header and single payload. So in my extended operations, all these payloads can be different operations. So you can put multiple operations inside the if, while, and all. So this is the scratch pad of operation. Like you can specify an offset. That's the kind of you can say register number or variable number. And then the you can also I already told like you can write another operations result also in the scratch pad region. Then you can perform mathematical operations as well. So most of the usual ones are implemented. Then there is decision making and loop operation. So I have just put like there is an example of any if operation. So I just wrote to the scratch pad register five one, then if up and five means that if that scratch pad register is true, then we'll go to the if, otherwise we won't. So I am doing a manifest read operation, then decrementing it. So if I run this again, then this won't be executed on the remote node. So this is actually going to be executed on the remote node. Then I'm just doing an I square C read by it and write that particular read by it value to the scratch pad resistors. Similarly, you're performing a while. So this will this while will run five times. So I just wanted to see whether can this set of operations allow me to make a robot. So I wanted to run a control loop on using this set of operations.  So it has some few IR reflective sensors which takes inputs. And so if it deviates from the line, we get the IR sensor input. So we can compute the error according to the error. We control the motors. So in the normal gravers over like for IoT, you can send this transaction over the remote or the sub-gigards wireless. But I did try the latency. This was kind of 50 millisecond for transaction and you cannot actually do a control loop with that kind of latency. So what I have done is that like I have put the sequence in the same with using the similar the previously described operations and try to offload the control loop to the remote node. So here I have the demo. So this is also being developed run on a big old play as a gateway. And so I'm doing the network setup. And it's running the same gravers firmware as earlier. And also you can see the, so I'm just showing you that there are onboard sensors that shows up in the kernel also as before to just show that it's the exact same firmware. So I just started a Jupyter notebook on the big old play and I'm just doing all the, since it's a prototyping, I'm just doing it on using the Python. So, so I'm just like running all those. And so in the end, what you'll have is that you can describe different transport also using this library. So I'm just using the TCP IP. So you can see I am so in the end user gets interfaces like the big old connect freedom dot get manifest or big old connect freedom dot set GPIO offset. It's an easy user interface for the end user. Like, and this is not using the kernel grab us now. I'm just showing the grab us manifest, which is the module identifier information. So this Jupyter notebook has all the different operations implemented and I have added it in the references as well. So here I'm trying to read the onboard sensors on this board you through grab us transactions, but not generated from kernel but from this experimental Python module. And for that robot there was also a PWM micro bus add on click board that was used to control the motor speeds. So this was some failed prototype. I tried to maybe try to run the control loop over wireless. It did not work. So this is the final code that it look kind of looks ugly like assembly and you have different operations where I kind of calculate the error control the motor according to this. And so right now I have dispatched the sequence to a big old connect freedom on a line tracer robot. And you can see that's running a control loop, but there is no actual firmware Lord or firmware change on that device. I'm just sending a sequence of operations that I'm offloading a sequence of operations to that robot and the control loop is run locally. So once that set of operations are send out, the even if the gateway goes down or the host goes down, that will still continuously be running. And in addition to that, when it's running, you can control parameters of that control loop as well from the host. So that also I'm doing it now. So I have some helpers to just the update the speed just changes the PWM duty cycle. So the control loop is running offloaded to a separate thread and it's running in parallel. And then you can also send more sequences or more operations and do more things in this at the same time. So I'm changing the motor speed from the it's being done remotely, but the control is loop is not affected at all. You can change do other things. You can interrupt the control loop as well. I stopped the robot. I can make it go back then do the control loop again. So all this you are not doing with any firmware Lord. You are just offloading different operations over grab us to the device. So one nice application I could find was so when we used to make these kind of robots while we were in college. So what we used, we had a challenge of tuning this PID parameters. We used to take out the robot and update the parameters, then put it back, update and do it again. So now you have you are developing all this on your host system and you can have like interface with more and more middleware. Like, so let's say you have on the scratchpad registers, you have something like a K P K I K D and your control loop takes that as an input and it runs in parallel. And you can send a message to update these values from the host continuously without taking out the word. So you can interface with more and more middleware like rose or other middlewares since you are doing all the development on a Linux whole system. So yeah, I admit the interface available to program or send the sequence of operations. It's not very straightforward. It's kind of some like you are sending and if then it's slightly difficult and not very straightforward. But the way how grab us for IoT with the Beagle connect freedom comes up. It's very straightforward and you are just using the sensors and devices on the remote module as if it was on the Linux, your host and you also have device drivers getting probed with them. So you may not be able to directly use it at that maybe and as an add on to that if you want to do offload control loops or other operations, you can use this. And right now how it's implemented is you send a group of messages and it's offloaded to a thread. So if you run more than one kind of loop, you will need to take care of the synchronization yourself. So I have attached the references for all the related works. Also, I have added the details and instructions this Jupiter notebook. You can you don't need actual hardware. I tried it on Beagle connect freedom and Beagle pay, but it runs on the host itself. You can use this effort native POSIX target build it and do development experimentation on the host itself. So this work takes input from a lot of different related works. So I would like to thank them all and thank you all for listening. Yes. Yeah, I'm planning to find time for that. We have plans. No, not yet. So you want a way to make do some decision making on the remote node. So for that, you are using the scratch pad as temporary variables. So let's say you perform an I square C read, put it to the scratch pad register. You write another constant to another scratch pad register.  You can do different actions like that. It's kind of temporary variables. I think both of you have. Yeah. So if you so you want to create a great virtual device with a keyboard on your remote node, if you wanted to make it appear as an HID device on your Linux host. So only thing. So and everything that's written is generic. So I don't remember if we had implemented HID on the suffer side. There is already support in Linux side. So we might need to enable that. Let's assume that's enabled. You will need to change the, the grab us has the add on module descriptor format called grab us manifest. That's where we describe what all are there on the module. So you just need to have update the manifest. So right now all you will need to refer to the grab us pex document and update the manifest. And there is also a manifesto tool that creates this manifest binary. That also is a good, there are good references on that tool as well. No, I have not talked to anyone yet. So I think like a byte code interpreter like ebpf, that would be great. But one advantage that we have here is that you can have like very large kind of operations as a single transaction. So if you think of ice and I square C read, if you want to do it using raw or you want to call it from scratch, then it will be slightly difficult and it will be platform dependent as well. So with the grab us operation and the, the, the grab us module running there, you can just send the standard grab us message, which says to do an ice square C transfer. Yeah, I think that's just one benefit I saw. But if you really want to do any like complex development, this way might not work really well. Yeah, Linux driver because the Linux device drivers does not have the information about that. I need to think about it, but right now all these device drivers, the OPT 30 and all this we use was the direct device drivers. There is nothing for grab us that we did on that. So what one way I can think is you can do some more complex operations using the Linux device driver than do repeated transaction using this. Let's say you prop the device driver, perform calibration, all those complex operation, you upload it and get help from the device driver in the kernel. Maybe repeated measurements we want to do, we can do it from the user space. I did not do a measurement like that. Sorry. No, I did not do a benchmark benchmarking we should do maybe I was so without this extension, I could not run that control loop even if I was sending the transactions one by one. But with this, I can run that control loop. So I did just did that kind of comparison. Okay. Thank you everyone. So without. So I think the update rate I could achieve was around one kilowatts two kilowatts range. So without that I was kind of at 25 hertz. Thank you.


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.  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.  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.  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 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


All right, small bit and after dark for episode 10.31. This is a few new stories that we didn't get to. Here's one of them. So, Mike, we were talking about in the show, or we missed in the show, North Korea, Ukraine, Russia, and intercontinental ballistic missiles. Intrigue. What was going on there? So quite a few things. Over the past couple of months, North Korea has been testing some new missiles that have made world leaders worldwide freak out. So that if you can, let's just go ahead and start playing this video. They have a new rocket called Hoasong-12, which has a new type of engine that isn't previously based on any engines that they have. Now, a report from a British think tank blames Ukraine for this engine because the engine is supposedly too advanced for the Rodong engines that they've been using on the past, which are based off of Skud missiles. Now, Ukraine has been calling BS on this. They're saying that, you know, there's no way that these engines could have come from them because they haven't been manufacturing the engines since 1994. What you see on screen, though, is the R27 ICBM that Russia developed back in the 60s. Well, actually starting in the 50s. And North Korea bought one of those missiles, and this is the Hoasong-12 that you see on screen now. They bought one of those missiles off of two kind of corrupt design bureaus called Isayev and Makayev back in 1993. So they've been working for over 20 years to convert these engines into something that they can build themselves, not just use whatever inventory they were able to get their hands on. There's estimations that they had anywhere between three to four R27 rockets. They also got a bunch of Skud missiles, which they had been working on with Iran to develop into their different series of rockets that we're more familiar with. And they also got their hands on R16 rockets. And the engines, and the whole thing with this whole British think tank thing, though, is that the engine that it compares it to is a two nozzle engine called the RD250, which the Soviet Union used on the R16 rocket, and as well as the Cyclone rocket. And what you can see on your screen is this two nozzle engine, they arrange it so that there's actually six nozzles. But on the, excuse me, the Cyclone rocket that you see on the right hand of your screen there, there's three of these engines with the dual chamber. Now this British think tank, this report published by Michael Elliman, who actually is a missile expert who helped to help in the decommissioning of several ICBMs in the late 90s, he has surmised that they're using a single nozzle version of that engine. And the whole thing with this is it doesn't quite make sense. The size isn't quite right, and it does use the same type of fuel that the Huasong-12 and what you're seeing on screen now is the Huasong-14 that they have been testing. And with this it just, there's too much about this that doesn't quite make sense. Ukraine again has called BS on this entire report and have looked into their inventory of rockets that they have, and there are no RD252 engines that are missing. They have nine of these left in three Cyclone rockets that are just kind of sitting in storage. And Yushmash, the developer of this, according to their official statements, all of the RD250 and 252 engines they produced were sent to Russia long ago. So it's more likely that whatever source of this engine was was way back in that illegal purchase from Isayev and Makayev that North Korea did back in 1993. And there's just so much about this that is a bit confusing, and it turns out that Michael Elliman, the writer of this report, might have even some Russian connections. And so there's all sorts of weird kind of allegations going back and forth at this is some sort of Russian conspiracy to give themselves a reason to go in and continue the invasion of Ukraine. And interestingly, Russia has deployed troops to both the Ukrainian border and the North Korean border. So there's a lot of different things going on with this. But what I think is more likely is that this engine is not the RD250, but is based off of the R16 rocket that they got. Here's one engine that we have here, that this is a much more closer configuration to what North Korea is using now. The rocket you see on screen is the MR-UR100, or in other words, the mini-UR100 rocket. And the type of engine that it has is much more closer to the size that is on the Hwasong-14 rocket. The engine that you see there is the RD268. But there's another engine which they dealt with, North Korea definitely got their hands on, called the RD-0205, which is the upper stage of that R16 rocket. And they could easily have converted this engine, which is an upper stage engine, to be fired at sea level. So I mean, there's way more likelihood that they got these engines from that original purchase way back in 1993, and there hasn't been any sort of backroom deals from either Ukraine or Russia in the past couple of years. So that's what's going on with this. There's definitely a lot of drama. And as things come out, hopefully we'll be able to talk about it more. But yeah, definitely some scary stuff. Intentions are very high at the moment between the United States, North Korea, and all the other world players that North Korea might actually have an intercontinental, a true intercontinental ballistic missile and could actually follow through with some of their threats. But to be honest, in my personal opinion, and that's all it is just my personal opinion, I really think that North Korea just wants to have a deterrent. But anyway, that's what's been going on with that. So exasperated space, Mac. You were passionate about that one. You got into that one. I am. I feel so bad for the Ukrainians, man. After this whole Crimean thing, the Ukrainians have been suffering so bad. But huge mash is staying alive. They've got all these different deals. So they have that new Canadian deal to launch their Cyclone 5 rockets from there. And the sea launch deal is in the process of furthering along. And they'll be producing the engines for the Zenit sea launch version. So they have things going on. But they have been struggling really hard ever since the whole Crimean fiasco. So yeah, I'm definitely rooting for you, Shmosh. And I want to see more stuff happen. Well, thank you so much, Space Mike. For more Space News, tune in to tomorrow orbit 10 episode 31 from this last week to see what's happened relevant this last week. And then we've also got every Saturday at 1,800 coordinating Universal Time, our live show. So make sure to tune in to those live. Thank you so much for watching, and we'll see you guys next week.