 Kia ora, kouta, katoa. Welcome everyone. I'm David Robinson, gone with it as the name carrot. I'm a pentester at ZX Security in Aotearoa, New Zealand. For those who don't know where Aotearoa is, we're up the top of the map there. I enjoy, a little bit about me, I enjoy aviation and hacking. Queensland and Australia has a couple of great conferences with great hacker content but they're also on the approach path for their local airport so you can sit on the riverbank or on the beach and watch planes come and go. So that's a great combination there. Today we're going to be looking at electronic flight bags in the general aviation cockpit. We're going to go through some example issues and vulnerabilities and security type things and also going to discuss how we can mitigate the issues in each case. I'm going to go through these in more detail as we go through the talk. With the issues I'm going to present and with that quite a high level of the vulnerabilities, discuss more sort of classes and types of issues opposed to diving down into individual vulnerabilities. We're not going to be naming vendors or product names here. We're going to try and keep it general so it's helpful for everyone. We're not just sort of giving specific examples. Hopefully there's something that everyone can take away. Sort of for a bit of a framing of the talks of the issues that I've been going to present. While I've been thinking about discussing pointers to presentation together, I've sort of gone back to the CIA triad and been focusing on their integrity and availability sort of of the systems and how these issues sort of affect those. I will note that a lot of these EFBs and the receivers that are used by EFBs will say, you know, do not use for navigation or safety, et cetera, purposes. We know people are actually going to use them. People are going to put too much trust in them. So where possible, we should try and still make them safe if there are people using them in these situations. So what I'd like people to take out of this talk today is some ideas about how to make more robust and secure systems for their customers, for the pilots using their systems. There's going to be a particular focus on general aviation, the EFBs, but hopefully some of these ideas can apply for other EFB manufacturers and other parts of the aerospace industry. To an IT security professional, most of these issues and problems we're going to discuss will not be new issues. I will be trying to put an aerospace spin and examples to them to help tie them to the aerospace industry. But a lot of these issues, as we've seen industries move into a more digital, more connected world, we've seen a lot of these types of issues, categories, classes of issues come up as they've made this transition into this new digital world. So aerospace is not going to be the first industry to go through all these growing pains, nor is it the last industry that is going to go through this growth of product scope and have to deal with these issues. So what is an EFB in the general aviation context? It's often going to be on a tablet. It's going to have a, it's going to provide the pilot with some combination of flight charts for navigation, airport charts that might provide some attitude and heading reference systems. So your artificial horizon, altitude, speed, direction. It may also provide some situational awareness through ADSB or FLAMN and it will be able to show the pilot what other planes and aircraft are around the plane that they're flying. So this is how a tablet and a receiver and the sensors sort of fit together. So in the middle, we have some sort of receiver unit. These are commonly, you know, and then we'll have the tablet with the EFB and this communication between the receiver and the tablet slash EFB is quite often going to be Wi-Fi. In some cases, it's Bluetooth. And between the receiver and the tablet, the most common protocol used is GDL90 and then some things will also use HTTP or WebSockets. The receiver will has, can take imports from a variety of different sensors. So an import, so we could have GPS satellites as one with ADSB in to help the situational awareness. We may have a gyro and a silisco, sorry, accelerometer that will help with pitch your role, acceleration, deceleration. In addition to the receiver sending information to the EFB or tablet, there may also be a web interface to the receiver where sort of configuration of the receiver can be done. And this normally happens over HTTP. So for my testing, I sort of only use my own tablets, my own receiver, my own hardware, where radio was involved, sort of, I did, you know, I made sure that my signals did stay contained to my test environment. So I used a Faraday cage where possible, I turned the transmit power down. I tried to use non-aviation frequencies. So if I could change the frequency used by the transmitter and the receiver unit, I would use non-aviation frequencies, where possible, I'd directly connect the transmitter to the receiver with a cable and some attenuators to drop. So the receiver want to get burnt out by the additional power. So I was really trying to make sure my system stayed contained to just my test setup. So there's a variety of examples and issues I'm going to go through. And I'm going to go through each one of these in more detail. So first up, we're going to look at heartbreak messages. So what this will do is the receiver will send a heartbreak message on a regular basis. The EFB will receive the heartbreak message and use that as an indication that the receiver is up and working as expected. And it can be used to inform the pilot that the receiver is not functioning correctly or the connection between the EFB and the receiver is not working. So as an example, if we start an EFB and the receiver is off, we'll often get some type of red X, some type of no, no connection, no heartbeat, need to know no, no connection established, some sort of error message, it's quite prominent and displayed. Most of them involved a red X, so it's quite clear that the system was not ready for use. So when we did start the receiver and the EFB connected to the receiver, the red X went away and started to display data, so heading, speeds, altitude, in this case. So what happens when the heartbeat stops? This can be because we turned the receiver off. It could also be because a malicious individual is tampering with the data in some way. So what do people expect is going to happen? Do they expect the EFB to inform the pilot, bring back the red X, or do they think everything's just going to continue on hunky-dory, everything's going to be fine, like nothing has happened, it's all okay. So who picked just continue? Well, that is what happened in some cases. You know, when the system is an integrated state, it should tell the pilot that the heartbeat message has just gone away, but I can't trust the receiver anymore. So when we are, you know, for these heartbeat messages, we need to make sure the EFB is using it as an ongoing check. It's not just a check to be used at startup, have all the components started up, it needs to be an ongoing check to ensure that the receiver is still up and running. Because in some of these cases, if you stop the receiver, it will just, the plane will just keep starting out, sorry, the EFB will keep displaying the same altitude, the same speed, or same location, rather than actually showing that there's an error. So it needs to inform the pilot that, you know, the heartbeat has stopped being received. And you could extend this out and start looking at other data. If you had been continuously receiving the altitude and every message to include the altitude, there's suddenly the altitude field was no longer there. That's an indication that again, if something's wrong, and a piece of data that the EFB was expecting or had become used to expecting has disappeared, I make sure to inform the pilot that just because the altitude has disappeared, other data may not be as of the high quality as it was before. So the validity of data. The data that EFBs receive from the receivers may not always be valid. Likewise, the data the receivers receive from the sensors or other impots may also not be correct. Receivers sensors have faults which could result in bad data being sent. There may be corruption happening on the wire. A malicious individual could be injecting or intentionally manipulating the data to make it malicious. So one example is headings. This is a test I did was normally a heading in aviation between 0 and 359 degrees or 1 and 360 degrees, depending on the particular limitation. But what ever happens, the heading should not be more than 360 degrees. So in one case, with a dummy receiver, I sent an EFB and a message where the heading was 450 degrees. It was actually remapped and displayed as 90 degrees, which if you take a step back and you think about the underlying math libraries, which the FB may be using. When you talk about degrees and degree maths, you know, 90 degrees make sense because you've got 450 degrees. So you go 360 for a whole circle, then another 90 degrees 450, you know, in the math domain, when you're dealing with angles, that makes sense. But in the aviation domain, yes, you know, headings are measured as degrees, but we're dealing with headings, not degrees. So in this case, we... Oh, sorry. In this case, you know, in aviation, it's 360 degrees. So if it's more than that, we know it's actually an error. So we take a quick step away from EFBs. And we think about another system where there can be pilots presented with information in the user interface, which informs the pilot that there is a disagreement. There is an issue with a sensor. A recent case has been with 737 MAX and the MCAS. One of the things have come out that the angle of attack indicated the AOA, there's a disagree warning. This wasn't optional extra, the airlines could select. And I understand in the MCAS changes, this warning is now... It's going to be implemented on all 737 MAX aircraft. And what this warning does was displaying that when the sensors no longer send these multiple AOA sensors on an aircraft, when the values differed, it was going to warn the pilot there was a disagreement. So the pilots knew that this piece of data could not be no longer valid. And maybe they need to use other sources to cross reference and understand what the issue was. So it would be good if EFBs, when they start to detect the data may no longer be valid. It's going out of bounds. It's not what they expect. There's a disagreement. It would be good to see if there was a type of warning, if an EFB could provide some sort of warning as the 737 MAX does with the AOA disagreement as one sort of recent example. So this can be when they start to disagree or they go out of bounds, like the headings of the 450 degrees that's out of bounds. It's an indication there should be an error. So what EFBs and receivers should do is they should know what the data should look like under normal operation. They should be checking that their expected data is in the correct range. And when it's out of range, inform the pilots somehow or stop the information being sent so people cannot make the wrong decisions about it. Or you know that you shouldn't be relying on a sensor that is having a fault. Additionally, you look at the trends in the data. You know, if you've been, if the vertical speed results in an altitude change sort of completely out of bounds, maybe you should stop displaying altitude or vertical speed. So for instance, if your attitude suddenly changes 10,000 feet in a few seconds, either there's a fault with the plane and the pilot already knows about it because the plane is dropping out of the sky, or there is a fault with the receiver or sort of the altitude system somehow. So in that case, you should inform the pilot, don't trust their altitude, go trust one of the other instruments that has given you altitude and rely on that. And it may indicate that other sensors involved, which the FB users may also be invalid and the pilot should not rely on them. So with the situational awareness that pilots can have of the aircraft around them, there are some sort of denial of service scenarios. So what some of the FBs do is they have a movie map, which is normally for navigation, showing you where the navigational aids are, showing you your route. But additionally, if the system is capable of ADS-B, it can start showing the other aircraft around and where they are. And with software to find radio, it's easy to transmit ADS-B out. Renderman has and others have discussed this previously at many other conferences. I've learned some other talks at the Aerospace Village on ADS-B Spoofing as well. So this is sort of roughly what it looks like. We've got a movie map, we've got the aircraft, we've got its route and we've got some other planes around it. So what I did was I did a situation where we had this plane and I injected a large number of planes around it. So it's going to be a really congested, super congested airspace. Lots of conflicts, lots of potential path crossings, a lot of potential hazards. So when I broadcasted this, I was expecting the AFB to show all the planes that I broadcasted. But in some cases, you know, on the right there in the diagram, I've just popped up. As we'll see, some of the, it doesn't actually necessarily display all the planes. Some of the planes were being dropped off and then missing. It wasn't always the furthest ones away that disappeared. So it wasn't some sort of range thing. Off there's too many planes. I only showed the closest X number of planes. I couldn't really determine a pattern that resulted that of what planes were missing. And also if I replayed the same input data into the system, I wouldn't necessarily get the same output. So without sort of further research and diving into the code, my current hypothesis is that something to do with the way that the timing of the message received and how it packages up X number of planes to send down every half a second or every 10 milliseconds, depending what the, how often it's sent the current list of planes and there's some cut off and buffers. That's my hypothesis. I'm entirely sure it's just saw this pattern of indiscriminate planes being dropped off. And, you know, this ADSB spoofing that can be combined with TKS issues. I think Pentes' partners Ken talked about this back in May. I believe there's also a talk going on during the Sarah Space Village about this and more depth. But what I'll say on this is with ADSB and TKS, and TKS is the traffic collision avoidance system that you can actually help. You can start putting in malicious ADSB targets to help reinforce the pilot. There is actually a real TKS issue. It's not a malicious one because you can make the two sources correlate with each other. So you could have a malicious plane come in and then you'd start to get TKS messages maliciously, which will come in and reinforce that as well. So whilst discussing some TKS, TKS and some instances from what I said has directional antennas. So it can tell where the TKS message is coming from, whether it's to the left or whether it's to the right or up or down and so on. We could do the same with ADSB antennas. So we know where we know where the aircraft should be based on its location in the ADSB message. But we could also look at the direction the signal is coming from to ascertainers. I believe the plane's over there and the signal's coming from over there so that they most probably correspond. But if the plane's over there and the signal's coming from another direction, we know that possibly this is a malicious ADSB message. So if we've got that, we can roll them out. And the ADSB receivers, when they are not going to pass down a full set of aircraft, there's somehow dropping aircraft, it needs to inform the downstream systems, in this case the AFB, that there is an issue and it is operating in a degraded state. Additionally, if the AFB is dropping planes because of some limitation it has, it should also display some indication that planes are missing from the display and do not, you know, do not use this as a situational awareness tool at the moment. So GPS spoofing. From what my test end and from what I've seen, GPS jamming, GPS signal loss sort of handled quite well in the AFBs. There's either, there's normally indicators that there is an ADSB, sorry, a GPS fix, and there is also an example when there is no GPS fix, there's an indication. But when we see malicious GPS signals, this is not the case. So we see, we're a malicious GPS signal, what I'm thinking of is sending a valid GPS signals replicating a set of satellites, which result in the aircraft determining the wrong position. So last year's aviation village, there was a talk on ILS spoofing and which involved, which involved in the result of aircraft potentially having the wrong horizontal offsets or the wrong flight slope and resulting the planes landing in the wrong location. One of the cases here was, oh, GPS and G in this RNAV can be used to cross reference, you know, the glide slope and stuff. So they should be lining up. And if they don't line up, alert the pilot and they can make further decisions about going round and ascertaining what the navigation systems are. But we could also use GPS spoofing to match up with the ILS spoofing. So they're actually going to correspond to this cross check no longer becomes a cross check because they're both incorrect. But they're both they're both incorrect, but they're both showing the same values. So there is no cross check and there's no indication that one of them is wrong. So back in 2017 at DEF CON, I did a talk where I was doing some GPS spoofing research that was mainly based around time and manipulation of time service. But what I did during that thing during that research was looked at how we could go about detecting GPS spoofing. And in that case, I came up with a bit of a proof of the concept tool called GPS snitch. It's not production really. But what it was was looking at some of the GPS parameters, signal parameters. And so it was possible to actually detect when GPS spoofing was happening. So for a start, GPS is the maths is all based around the GPS satellites broadcasting time, very accurate time. And then based on the time offsets between the different satellites, math happens and you get a location. So if we've got a clock on the receiver that has been synced up with the GPS when we first turned it on, you know, the time should stay and sync together. But if we suddenly start GPS spoofing and there is the GPS receiver locks onto this spoof set of signals from a range of spoof satellites, we'll notice the time will jump whether and it might be, you know, 10 10 milliseconds ahead of time, five milliseconds slow. But if we get sudden change in time, that's an indication that a spoofing that's happened, trying to get trying to start up and have a spoofing attack, start with a time with some millisecond accuracy is quite a difficult task. And that's one parameter. There's other parameters. And I found that actually when you looked at more parameters, it was actually you get a much more stable system, particularly if you're leaving it running, you know, dramatically left it running for a day just to see what the natural variations were. And I found that sort of one look at one attribute wasn't really enough. You need to look at a range of attributes. So if you're in a case in an aircraft, if the location changes more than what the current speed allows, that's an indication that, you know, it could be GPS spoofing, because you know your velocity and if it changes, if it's you're outside of that, you've got a sort of a circle of uncertainty, which may be valid. And if you've outside that, that's a potential issue. Also, look at the GPS signal strength. GPS satellites are 20,000 kilometers away, give or take a bit. So the overall strength of GPS signal when it gets down to ground level is very low. And also the so suddenly if we get a GPS signal, suddenly raise in strength a lot, it's possibly an indication that a GPS spoofing attacks happening because the transmitter of the fake GPS satellites is going to be much closer. So matching the signal strength is hard. Additionally, we should have a range of signal strengths because the satellites directly overhead seem they are closer than the ones way out at the horizon. There's they're going to have different signal strengths because the distance traveled and the amount of atmosphere they have to travel through. But suddenly if the range of different civil strengths decreases, that's another indication that malicious GPS transmission is happening because when you're doing the malicious transmission, chances are it's all coming from one transmitter and it's going to have a very similar signal strength. So additionally, like we said back with the TKS and the GPS was again looking at the signal direction. We know where the GPS satellites should be at any given time. We know the plane's current location. So we know in what direction the GPS signal should be coming from for each of the satellites. So if they don't come from expected direction, it's an indication that they might be GPS spoofing or a GPS attack happening. So what we need to do to help mitigate some of this risk in the airfields is they need and the receivers, they need to start monitoring GPS for abnormalities. So like with some of the topics I talked about with the GPS snutch. Sean indicated that when you have no GPS fix, when you detect the spoofing display GPS, no GPS fix because you can no longer trust that as an import, market is no GPS fix or degraded GPS fix or something whatever meets the relevant terminology and accuracy standards. So integrity of the data, the data sort of in the overall system of receivers and AFBs and sensors, it's nearly always happening in clear text. There is an encrypted version of GDL 90, but from what I saw that was not in very common use. My guess is it's a bit of a chicken egg problem. The receiver manufacturers don't see the point in implementing it because none of the receivers, sorry, none of the AFBs are implementing it. The AFB manufacturers don't implement it because none of the receiver manufacturers have implemented it. Additionally, the Wi-Fi is often open and in clear text so anyone with an range can connect to it with no authorised, with no authentication required. And also, there is when you first sort of pair an AFB and a receiver, there's no key material changed. So you can switch out the receiver and the AFB will still keep talking to if it's the same sort of SSID for the Wi-Fi and the same Wi-Fi password, it will just connect fine. No, it sure won't inform the product. So, you know, think back to your headphones and your phone. When you get used to their Bluetooth headphones, you need to pair your headphones and your phone and they are connected and they're only going to talk to each other. You know, if you didn't pair them and you didn't have this sort of checking that they're talking to each other, as you're walking down the street list to the music, you'd start hearing the music of everyone walking past you. You know, and we don't want that to happen with our AFB. We want to make sure we're getting the data from our own plane, not our friend's plane. So, you know, if you have a friend who you're doing some formational flying with and because you're friends, you've discussed receivers and you've settled on the same sort of receivers and AFBs because you both like them. You don't want the situation that everyone's left with the default Wi-FIs and the default SSIDs because it just starts working. You don't want the AFB in one aircraft connected to the Wi-Fi in another aircraft around it because that's going to be bad if you're receiving data for a different aircraft. So, what we should look at here is where possible, start making the migration to GDL 90. Have receivers start to say, you know, on the state, we're going to implement it on the state further down the track. We're only going to have GDL 90. Likewise, on the AFB front, make sure, you know, your system is just set up to actually accept it. When you first pair an AFB and a receiver, make sure there is some exchange of key material. Make sure there is a pairing process to couple them together so you can't introduce malicious receiver and have it connect and have the AFB connect with no error messages. Make sure you sign every message so the AFB can trust that it is coming from a receiver that it trusts. If the message is not signed, disregard it and additionally, ensure there's some protection against replay attacks. So, make sure that malicious thing that you can't capture a packet or a series of packets and have and just replay those over and over and over again. Make sure there is some protection that they need to actually keep changing it. It is rolling. So, to find something, is part of my job. I look at devices, systems, hardware and to make sure they are robust, you know, these testing ventures that have got vulnerabilities but also checking that they're robust so even if they're a vulnerable, I don't know about their attack footprint as small as possible. And when I was looking at some of those of the receiver devices I was put this hat on and I was thinking, you know, have they made the attack footprint as small as possible? In some cases, you know, they had made the attack footprint bigger than it could have been. For instance, you know, there was a receiver that had an internal fan and based on the receiver's temperature, it would put the fan speed up and down to keep the system at the optimal temperature. But instead of setting it up to the fan controller, only listen to commands coming from inside the device, they could figure it so it would accept commands from anywhere in the Wi-Fi network. You know, and that's wrong because in case the only thing the fan controller should be receiving commands from is the temperature sensor inside the receiver. So when the temperature sensor notice the temperature raising, it needed to tell the fan to go faster and vice versa. Additionally, there are weak Wi-Fi configs sort of as mentioned before. A lot of them are open. They don't have pre-shared keys. They don't use WPA2, WPA3. You know, using, you know, pre-shared keys, they will put protection on it. So A, it will encrypt most of the data. B, it will mean that only authorized people can connect to that Wi-Fi network. So you won't have malicious and rogue things connected into the Wi-Fi network. Though even with the encryption, even with the WPA, WPA2, there's still some attacks you can do against it which can have downsides. For instance, there's there's management frames which sort of below the data and control the sort of the Wi-Fi connection. And there's a particular message called a deauthentication packet. And what that does, it's set from the access point to the receiver. So the access point in this case would be the receiver device and the wireless client would be the tablet slash EFB. And what the access point says is say, normally you'll say, hey, please disconnect, re-establish because I want you to re-authenticate. So provide me with the password and whatever again. My problem is these messages aren't signed normally so anyone could come along and set the authentication packets. And this results in sort of two possible cases that you get a denial of service because the EFB or tablet will no longer be able to connect it just keeps being told to re-authenticate. So I'll connect, get a packet to say re-authenticate so disconnect, deauthenticate and re-authenticate again. Additionally, it can also be used to steer the device and steer it to a legitimate receiver. There might be a malicious receiver. So what you do is when it's connected to the legitimate receiver, you send the authentication packets when it's connected to the malicious receiver. You don't send the authentication packets so stays connected to that. So the EFB is receiving data from the malicious receiver rather than the receiver that the pilot put there. There's also additional services running. SSH is a common tool used for remote access to a device for configuration. So in essence, production devices don't need SSH enabled at all because they should be in a secure, hardened format. When it's not an active development or active debug, you don't need the access to the device. And even digging into further, its configuration was not in line with best practices for the use case and following hard-dened guides that had basic things like port forwarding turned on, root long-ons turned on. A lot of things that you wouldn't normally see in something you'd see in the default sort of installs just to make it work but hasn't shown the additional hard-dened steps that have gone through. Also, the web config user interface had no password on first use, no password change on first use, no password at all. So even if the Wi-Fi network had a pre-shared care and password, as I mentioned on the previous slide, you should also have a password on the web UI to control the configuration of the receiver. This is so we have security index. So we've got multiple layers of security control. So if one fails, there's still a safety net to stop it stopping the malicious individual getting further into the system. Make sure you have the safety net just to make sure things don't happen. So with this is make sure that, seek advice on how to harden the configuration. Make sure they're attacked for practices as small as possible. If components have hardening guides, make sure those are read and followed through and used to make the devices sort of secure as possible. So password management. So as I just said, web UI's often didn't have passwords on them or didn't prompt for a password change on first use. Going back to the Wi-Fi case that we used a few times now, there's sometimes options to enable a Wi-Fi encryption with WPA2, WPA3 or with pre-shared keys. One when it did this said, came off a message saying, we've securely set up your Wi-Fi, you're gonna need this password now, we're only gonna show you this password the once. If you forget it, you'll need to do a factory reset. So I went through, I factually reset it again, tried setting up the Wi-Fi, came up with the same password. Go across to a different device, also different instance of the same device, gives me the same password. So it seems to have been randomly generated, this password was hard coded, it always gave you the same password to be used for the Wi-Fi. But what, you know, and hard coded passwords, that is a bad thing. Additionally, in this case, I found it a little bit worse because the text and the messaging around the password setup gave the user their experience that this was actually gonna be a unique password, it was sort of randomly generated, it was secure, when in actual fact it wasn't. And that's sort of a double, makes it sort of doubly bad because the pilot or the user is not actually being provided with the correct information. So they can't make the correct decisions if they've been provided with the incorrect import information or documentation. So if there is a hard coded password that you're gonna use, say it's a hard coded password and recommend that the users actually set their own password or better yet, just randomly set a random password, give them a QR code that you can scan because most tablets and phones these days can read a QR code with a Wi-Fi password in and set the Wi-Fi up without actually having to type in a long password. You can just scan a QR code. Some of the FB applications had companion websites. You had to use these, you had to sign up some of the times because the FBs would not work without them because they had some sort of subscription functionality that free users saw so much paid users use this or you had to be a paid user, depending on the thing. And this allowed for flight plans or additional up-to-date weather information, sort of other non-free services that it gave you. I did not test any of these companion websites. I only went as far as registering an account on these websites. So when I did this, I noticed there were some issues. In one case, I got emailed a password in ClearText, which to me as a pen tester, often means that passwords are not being correctly stored in the database, the fact that a ClearText password can be sent for email. So that's a sign that incorrect password storage has been used. Additionally, you also saw some that allowed for weak passwords, so passwords that don't meet the standards of what people think is a strong password these days. Additionally, had some that said, oh, don't use any special characters. So putting my pen tester hat on, if I see a password field or some other user input field that says, oh, don't use quote marks, don't use dashes, and don't use the sort of other symbols. To me, that's a red flag that SQL injection might be available. They're trying to predict SQL injection by just not allowing users to use these characters. So if I was testing this for a job at work, if I saw text like, don't use the quote mark, first thing I'm gonna do is test SQL injection on it because chances are that's why that message is there. So password management. OWASP, the Open Web Application Security Project Foundation has a range of great check sheets. And these uncover password storage, password management, authentication, along with a range of other really helpful documentations. They've got stuff around building more secure web apps. Additionally, they've also got stuff on building secure mobile apps, which most AFPs are. So that's a great resource for information. So hopefully these example issues and solutions have helped you. And you've gone away and got some ideas that you want to look into your own products some more. So, and I hope that as you do future development, as you add features, as you test functionality, that you think, oh, what could a malicious individual do with this? You know, is there a way that they could affect their integrity or their availability of the system with what they could do? So sort of having this sort of what if hack and mindset and hopefully you can bring some of that into your testing and your development. Also, what can the security industry do to help their space industry in this regard? What help would you like from us? You know, would some example test cases of this malicious thinking be useful? So as an FD or receiver manufacturer, you can take these test cases on board and start working them into your systems. Would a test harness that was say a dummy receiver at which talk to EDL 90 instead of, instead of just sending sort of valid helpful EDL 90, also sent malicious payloads and started pushing the boundaries a bit more, would that be something that was helpful that you could set up this test harness for this receiver, connect your FD to it and have it sent all this malicious information to help you if you're testing, help the automation of the testing, would that be something that's helped? So really good to hear some feedback from the industry. But you need from us as well. So thank you. Hopefully it's been useful for everyone. I really love to hear feedback, chat to some people, because if I'm passionate about it, I'm sure there are other people here out there who are interested about it. All that's why you came along and listen to this talk. Thank you very much. See you all later.