 My name is Brandon Bailey and I work at the aerospace corporation within the cybersecurity subdivision. And I'm here today to talk about some research we've been doing on trying to figure out how to unbox the black box space craft software is starting to become looking for weaknesses and vulnerabilities in this software. There's a couple of links to some papers that have been published in the last couple of years related to cybersecurity for space systems. If you are interested in learning more about that topic, please give those a read. So let's jump right into it. So the problem that we're really running into right now and the driver for the research is we're having a commercialization of space that's kind of expanding the usage of open source and third party software within our spacecraft architectures. And in the past we were operating with more of a white box mentality, and we had full source code access at times and now we're moving into this black box ground where we're not really sure all the components that make up our spacecraft software. And it really makes it difficult for software assurance providers. And so we're trying to figure out how do we tackle this problem moving forward as we are getting more and more black box software to perform mission critical activities. So we perform some research to identify tools and techniques on the market or open source that could help evaluate the security posture software without the presence of source code and that is a key element of this. And we also wanted to kind of tailor the research as much as possible to hardware architectures that will be typically seen on common spacecraft that that could be your power PC arm spark and those type of. So we wanted to figure out, could we automate this code inspection mechanisms and cost effective fast and repeatable manner. Could we look into you even if we had the source code maybe assess the quality as the as built flown components. So sometimes you may get pilers that put in weaknesses. And we did focus on embedded applications and embedded architectures, but we did look into some of the more standard x86 64 binaries, because that is a problem area as well, especially for ground systems. The ground system flights, the ground system software that we are working with these days is also becoming somewhat of a black box so we wanted to not leave that out but really did want to focus on the embedded side. And as, as earlier stated earlier we, we wanted to look into the integrity to build process and see if there's any vulnerabilities that were introduced by compilers. So, essentially the goal was performing software assurance of spacecraft binaries without having access to source code. And while we're doing that we did get the tinker around a little bit with if we did find some weaknesses and vulnerabilities in the software could we bridge the gap into exploitation. So we'll talk about that as well. So what is software assurance and specifically software assurance when you when you deal with security assurance. So, in, in our opinion, it has five major technical analysis approaches to help you reduce the risk of vulnerabilities and software risk. So, pretty much a standard practice in today's world is when you have source code, you perform static code analysis for looking for the exposures of common witness enumerations or CWBs. You're looking for best practice adherences you're looking for coding standards violations, code complexity, code functionality those type of tests. It's less standard for binary. And also for a security assurance, you may look into the kind of the vulnerability analysis, which will be kind of identifying the known knowns that those will be your common vulnerabilities and exposures. So that would be CVEs, or maybe if you're in the government you're assessing some sort of state compliance or CIS benchmark. Something that's becoming standard in the software assurance community that is long overdue is probably the dynamic analysis dynamic testing of the software trying to break it. While it's under execution so that could come in the form of penetration testing that could come in the form of fuzzing. It's been pretty standard for the most part from a functionality based perspective. We have a pretty good testing program for functionality based testing but you're starting to see the expansion of this into the security realm and doing fuzzing and doing red team type activities and pentest type activities against the software. And something to note is with the spacecraft specifically and in the embedded architectures, advancements with digital twin technology in the last 10 years has really allowed for some of this dynamic testing to occur. So that will be your being able to use instruction set simulation to build out simulators that you can run these embedded binaries without having the hardware present. So another thing that's becoming standard that is not quite adopted across the community quite yet is like your software build materials as bomb software composition origin analysis to help identify this the components within your in your software and looking for CVEs as well as any open source licenses that might put you at risk. So this is the kind of the five areas where I would break down software security assurance so I'm not saying this binary analysis technique that we're going to discuss is the only solution for software security assurance, but I am saying it's a key component or can be a key component especially we don't have source code. So we're going to dive right into the, to this, the binary so the binary analysis static code analysis is where you could typically find some of your CVEs. This, this origin analysis or software composition analysis and vulnerability analysis will help find your compliance and your CVEs and your zero day discoveries will be more in the dynamic analysis of fuzzing. Four of the five are pretty well researched and binary analysis is becoming well researched, but it's, it's not quite, you know as widespread known on the, on the embedded side. So that's what we're going to focus on the embedded aspect, and not so much on the windows and Linux aspects of it. And when you talk about binary analysis, what do you actually mean. So I've met with vendors I've spoken with a multitude of analysts in the in the last few years, and it can mean a lot of things to a lot of different people so we're going to define what we mean by binary analysis for this presentation. So some people say binary analysis is really composition analysis, which there's an aspect that is true for origin analysis is often referred to. So that's not what we're talking about. Some people would refer to binary analysis as behavior analytics. So it'd be kind of like the malware, more malware focused analysis was sandboxing in your cuckoo sandbox and those type of things, where you would do behavior analytics on a binary to determine kind of what what it is and that would be like required an execution environment. And then there's the dynamic execution some people would say binary analysis would include binary execution, which has some merit but that's not exactly what we're talking about some people would say binary analysis is has some buzzing components which can be true. But, you know, and others would say, when you say binary analysis, a lot of people jump straight to this mindset, which is typically where I was before performing this research, so I would assume you're doing binary analysis you have a debugger you have a disassembler you reverse composing the binary, you're loading it up in in a product like giger pro and really decomposing the binary and going through it. Problem is that's very labor intensive and very specialized skill set. So what we're looking for are things that kind of are synonymous to what we would once call static code analysis that will be scalable pool sets that can do binary analysis across a multitude of potential weaknesses that we can look for false positives and things like that so that's that's kind of what we're looking for through this research and that's what we'll talk about. So, correlated to the earlier the list on the previous slide. This is a sampling it's not it's not, you know, an exhaustive list across the board but these are some of the things that we looked into as it relates to buyer analysis and what our focus area was. So our focus area was down in the bottom left so this was looking at costs applications that do the quote binary static analysis we looked at the free and open source software that does that. We looked at a little bit on the reverse engineering disassembler area, because those can be used as as extra tool sets. Once you get the results from the binary static analysis. And then we looked in the little bit on dynamic execution side like how easy would that be without source code access and how beneficial it could be but it could be extremely time consuming if you don't have insight into the binary like source access. We looked into fuzzing as well. The fuzzing is not very mature on embedded platforms from black box perspective so that's, that's, that's kind of focus on so if you're a range, kind of what we've discussed on on a tiered pyramid here. I would, I would view things as like this is kind of like static code analysis so the tier one would be, you know, a lot anybody can really run a static code analysis tool for the most part, especially the ones that don't require compilation you can just throw a source code repository or zip file at a tool and it'll spit out some results. That'd be like a tier one analyst but here to tier three analysts would be the ones who have to dive into the actual source code and the week and the the alerts and decompose if those are false positive or true positives. And that takes some time but that's a pretty standard practice and it requires some knowledge of just the coding language that's under use so that could be like CC plus plus or something like that. So, but on the binary side that's similar a bit different so a tier one, we're looking for tools that can help with this tier one and tier two analysis to help move us to the tier three level so the tier three level would be the people who understand disassembled code assembly knowledge and things like that. So that's a much harder skill to come by, and not everyone can kind of do that so you can't take a standard software developer per se, and expect them to really understand how to follow assembly code and looking for we just small abilities and assembly code. So that's kind of what we're talking about. And the, the one thing you with with binary analysis what we found similar to the static code analysis is there's no one tool there's no one to forget it you can't just throw your binary or through your, your press it file into a tool set and have all the results come out be pristine so the set forget it silver bullet doesn't exist, nor do we expect it to. So interpreting the results like I said takes software development knowledge assembly knowledge, you may need architectural specific knowledge, as well as potentially operating system knowledge. So all those requirements for spacecraft binaries, you know that that that moves your way up to the tier three area where it's very specialized. So, we were trying to see if we could find these tier one tier two level binary analysis tools to help us out to help process. So let's jump right into to some of the results. So we're looking at the automated binary analysis that really resemble static analysis so to generate insight about the binaries. You typically in, in the past you would you analyze source code, and that's obviously not possible when you don't have the source code, but one of the good things that's occurring in the embedded market with the Internet of our cyber security becoming important is there's tools coming to market that can help really analyze some of these less traditional x86 64 binaries and pull out some potential weaknesses and vulnerabilities that we need to dive into. And then you can jump into those with this assemblers like get your IDA to really dive into the details. So what we'd found, you know, probably a few years ago is most of the COTS tools that were out there that discussed binary analysis were really those component and origin analysis tools but the market has responded accordingly, which is great. And some of the open source pieces of software that are out there are great and they're really good tools but they do require a lot more activation energy to get started. They're not as easy to just jump right in. There's a steep learning curve in some cases. And we explored some of these options just to see what that ramp up was like. You know, looking through our survey and looking through all of our tool market studies, we looked into bear code, and then we basically had to dismiss them as a player in our use case because we're supporting the government and they were a cloud only solution so on the COTS side it really came down to grandma tech who has a binary analysis component to their code sonar product line and then Blackberry Jarvis as another. And then we looked, we singled down to a small list of freed open source tools from Bain, the Rose Compiler, Faro's, which is from the Carnegie Mellon Software Engineering Institute, and the CW checker as well as the anger framework. So we looked into all these to see if it could help support our use case of static analysis, binary static analysis without source code, see how that stuck up. So bottom on up front is both Blackberry and Grandma Tech's code sonar, you know, they were pretty much the only commercial tools that we looked into based on our market research. And we also found some strengths with Jarvis being in the embedded world, which was great, because it really fills a gap where something like code sonar has pretty decent performance in the x86 area for Windows and Linux binaries but not really much support on the arm power PC and spark area. So we did, we did look at code sonar's beta release, they haven't released full support for power PC, and we looked into that how that performed in it, you know, it's still early on for that support level so bottom on up front. If you have embedded systems, which is what we were really focused on with your spacecraft binaries arm mips power PC spark those type of binaries Jarvis was pretty much the only solution for that problem set. But it's not a silver bullet either obviously so showed the most promise. And we scan a bunch of different types of binaries compiled from various types of pilars. Bins Vx works hot software for a bus new bus architecture firmware from a router. We attacked we were successful in detecting some backdoors in some links binaries so when we actually did test some known knowns with Linux, we found some backdoors which was great. And then we found a buffer overflow exploit in an arm router firmware so that was great as well. The tools showed a little bit lost promise. And a lot of those you know they therefore built for purpose for a single purpose, and they're not you know really commercialized into these which you wouldn't expect so they're niche areas where these come in handy. Tuma is promising probably but require a lot of work with them or the anger framework and the rose compiler so both of those frameworks are really what they are provides great capability but there is a steep learning curve for those and a lot of work on the front end to get them integrated in to analyze your binary especially we don't have a source code. So we looked at also looked at bang and Faro's and nothing nothing really if any subsequent come out of that analysis either and Faro's was really looking for Windows pe binaries was was their focus area so the one possible that had some promise from what we the problem we were trying to was CW checker it it it was basically low overhead on usage had some false positives but did provide some minimal results so at a minimum, it's worth probably throwing this into the tool set just to see what you get out of but don't put too much stock and what you get out of it, at least from the work that we were looking into for the things we analyze. So let's dive into some details on the on the commercial side because that's it showed the most promise for the problem set for us that and we'll look at blackberry Jarvis first. So this is a bit of an eye chart but essentially it was just trying to articulate that you know we looked at much different architectures. Arm mips power PC spark are the four that we call out here and a multitude of different examples and what the point out on the on the far right is basically. These are the alerts that come out of the analysis and just it's mainly just to show. You know that it was pulling out results and we'll dive into the few examples moving forward. We also were lucky enough to analyze the real light and ground software so in an aerospace we have some unique access to information based on our customer sets. Obviously we're not going to divulge what these support, but at a high level, you know, we looked at some front end processor software. We looked at some different flight software binaries that were or instruments that we were given access to. So long story short is we were successfully able to analyze, you know, small that software pull out some interesting results. We were able to look at power PC instrument payloads flight software binaries pull out some interesting weaknesses from there. Look at some ground system front end processor software pull out a lot of interesting information out of those binaries. And one thing that start on the bottom which is kind of interesting to discuss is the AVR 32 architecture was something that the Jarvis tool set had never seen before. And it was a Cube set that was launched a couple years ago, and we had access to the flight software and we were given access and ran through the tool set Jarvis and it basically had no support for it. So we worked with the vendor and within a couple of weeks they had added that architectural support and we were able to get some some information out which was which was good. So that shows some flexibility in the way that tool set was built that you can add and support that quick. So that was that was nice. So we found some weaknesses but you know let's dive into the next phase if you find weaknesses you want to maybe confirm how legitimate they are, are they exploitable. So in order to do that we had to really focus on some kind of known known tests so this is where we would go a little bit away from the focus of the research on the embedded side but you know we didn't have a multitude of examples of known where they had known weaknesses or backdoors or malware inside the binary that for the embedded architectures that we had access to or could find during the research so what we did is we leverage the Linux binary with which had a backdoor in it for a VSFTP an old version of VSFTP and once you run Jarvis against that binary and go through the results you start diving into the information and it makes a it makes a alert that there's a there's a not sanitized subsystem call there and if you dive into it, you'll see this basically string right above the BNSH call that it kind of alerted on that is basically showing that you know there's some sort of potential backdoor there. Similarly, in this case of the unreal IRCD software from years ago also had a backdoor in it with a system call, you know, a mem copy before system calls it alerted on that as well. So it was successful in detecting that backdoor as well so that was interesting so it was these two old open source projects that had built in backdoors it was detected it in a matter of seconds which was great. So what about maybe something a little more embedded so this is from analyzing some firmware from a router on an ARM processor chip. And this is basically it discovered a scan f usage. And this was like a wake on land issue that that the software provided this capability and it took input. So after you know running Jarvis against it and doing the analysis and starting to build like a proof of concept exploit, you can basically send this, you know, exploit to the the web. You are I and you can trigger, you know, the exploit so this is just an example of trigger and a buffer overflow with this so the key here is the speed at which, you know, in all three of these examples is the speed at which this tool set helped us find potential issues that we needed to look into, as opposed to loading this information up into a disassembler and trying to find it ourselves. So that's kind of the benefit this far. Let's talk about. So what about some flight software so we also analyzed using the Jarvis tool set with some flight software. And this was an interesting one because we were, you know, we have some in depth knowledge of NASA's core flight software which is an open source generic flight software architecture that's been published on NASA. It's been used for various spacecraft over the years. And one of the one of the features of CFS that's built in is this memory manager feature which essentially allows for permission permitted arbitrary right to memory commands. And while this is designed to do this we were wondering if something like Jarvis or the other tool sets could pick up on the fact that you know they were basically writing arbitrary values directly to memory. And it raised some concerns on unsecure C API calls and did call out some mem copy functions but didn't call it the one that we were really looking forward to call out so that was that was interesting. So this wasn't necessarily malware this is just a dishonest law that if you only had the binary you were hoping you could find and in this case we didn't switch is a little disappointing but somewhat expected honestly. And we also had a flight software image that we used from old version that had underflow vulnerability in it and we were seeing if if we could find the underflow vulnerability and did not find that either so we found a couple backdoors and we found we didn't find a few things we were hoping we would find so but so what we wanted to do is maybe run some more of the. Tests, maybe I get something of more known knowns, and that's what we did so in order to do that we leveraged the Julia test suite that that's available online, which has essentially a multitude of weaknesses that have been pre programmed in the software. And we compiled these for embedded architectures and ran ran them against Jarvis just to see kind of what that would look like so that you know because it's hard to find known bad code, especially for embedded systems. It's, we kind of need to use something that we had, we could grade against of something of the known known tests, in addition to the ones we already did so this is just an example of some known known tests we use for Jarvis. And, you know, it performed pretty well from our perspective. So you're seeing a we've spent a lot of time on the Jarvis suite, because it showed the most promise for the embedded architecture so we're not going to have as much data on some of the other tool sets because it, you know our focus was the embedded architecture so it didn't show the other one. It didn't show as much support for that so it's kind of one sided from that perspective, but these are the results of that analysis. So now let's jump into code sonar and and code specifically code sonar for binary so code sonar program attack as a product that has been used for many years on the static analysis side and then a few years ago they added in this binary analysis capability and that's what we're going to look into so very similar results in some cases for for code sonar so this is some visualizations that grammar tech provides that something like Jarvis or the other tools didn't is this pseudo code and the, you know, the ability to kind of dive right into the the assembly that's there so Jarvis had the assembly printed out as well but the ability kind of click around and maneuver and jump from assembly within this framework was very beneficial and it's and it's decompiler that it has built in and the pseudo code generation is very helpful. And you can basically look to pseudo code as opposed to assembly code to figure out kind of what's going on. So that that is extremely helpful. So what about the known known tests for code sonar using that same binary, the vs FTP to 234. So it flag. It flags you something and it wasn't directly you know flagging the issue but it got you close to the issue and you were able to kind of you did throw analysis you would have more likely picked it up so so it's debatable if this is failure or a success but it's it puts you in the general vicinity and you may be able to determine the weakness so but it did not alert exactly on the right line of the assembly. So from that perspective it's probably a failure but it got you close and you may have you may have seen it as you're going through the analysis. So how about the same test on the on the CFS memory manager code. It also raised some warnings with some various calls and it didn't find the behavior either, which, like I said, it's a design feature of the application so it probably wouldn't find but you'd also want to find things that you miss things that may be considered for design or poor coding practice not saying that in this memory manager app is that it's just something that we were wondering to see if it could if they could pick up on because if you didn't know that it was designed that way you may want to know that this this application basically gives unfettered access you to the memory of the computer so just throwing that out there so to summarize some of the usage and coverage that we that we have so you know there's no one one stop you know one solution for anything they Jarvis had some of the best support for the embedded architectures and this table can really help show you what it looks like so Jarvis and codes on our does have a little bit of the fire and forget mentality you can at least there's not a lot of pre work that needs to happen you can just throw the binary in there and even codes on our on some of these other tools actually have pretty good integration with something like either pro or good job while others don't so if that's important to you know that's a factor. They also have differing varying you know support for various architectures between PEL you MIPS arm and the rest so so on the embedded architecture style like I said Jarvis provides the most support if you want some more support for the windows and Linux side above and beyond and codes are would be good as well as augmenting with some open source but if you have you know some very skilled talent that has a lot of knowledge on you know assembly and reverse engineering maybe I would get some benefit out of the rose framework or the anger framework. So just just keep that in mind but if you're looking for that tier one support for you know somewhat of a fire and forget mentality Jarvis and codes owner definitely appeared to be kind of the best in that area and it just depends on the architecture so this chart was kind of put together as a use case depending on you what you if you're well architecture using whatever binary you have you could potentially lever just flow chart to help pick the full set. So that's that's kind of the idea because if you were to come to me and say hey I have not say you would do this but if you had some sort of you know x86 64 binary on the windows side and you say I don't have a source code and I want to analyze it. For weaknesses. What would I suggest obviously wouldn't suggest Jarvis neck that point because it probably won't find much even though that can analyze it it doesn't really pull a lot of the information out from our from our testing. I would say maybe use something like Ferris or concern are depending on what you're looking for so you know that that's kind of how it's going to have to be is it's going to be a case by case basis and and you're going to have to make that decision based on your use case. So what about, you know, once you have these results from a tool like goods on our Jarvis or whatever tool you're using. How do you need to get from kind of point eight point B how do you know. Okay, it alerts on this area of the of the assembly. How do I know what that means so you may need to bring it up into some sort of disassembler. Tool set. Now customer did have their own type of this assembler and gooey in there but Jarvis just gives you a snippet. So you may need to use something like Gidra, which is just thrown here mainly just to educate people who may not be aware of it, which most people should be by now, but they do have the support that you need for the embedded architectures. It's free very it's a the community is expanding people are writing plugins so Gidra is becoming widely adopted across various communities. So it's kind of important to know that that exists and you may need to augment your binary static analysis tools that with something like this to help you dive into the binary a little bit deeper. So here's an example use case from scanning to exploitation so let's let's end the comparative analysis so let's let's go so let's go to the side by side comparison between the two commercial tools that had showed the most problems for us so Jarvis and goods owner for binary so. We wanted to, you know, analyze this vs FTP 234, and we, you know, run it through both tool sets, and we want to see, you know, what, what we have so we look, we find the area of the buyer looks interesting in the memory and we basically loaded up in Gidra and then we dive into it a little bit deeper and we can notice that the software is looking for the characters. Poland parentheses and then like a smiley face at a certain memory location so let's let's see what that looks like so let's tell them that to that port. And then let's provide the input. And then it starts up a listener on this port 1600 and then you can basically just. Netcat or tell that to that port now you've rooted the device or in that software so this is an example of you running the analytics on the binary finding something that looks interesting and then trying to actually manually exploit that. And so what's the what's the so what what's the big deal on that because people obviously found that backdoor over at some point in time so they may have done it through reverse engineering. I'm not sure how it was discovered, but what if you had you these this tool setting your toolbox at that point in time. So this is this is the interesting point so with you Jarvis or code sonar and you were just running these binaries through these tool sets and then kind of dive it into the details. Speculation, given that code sonar can give you the exact line number and get just punch you in the general direction where there could be an issue. Maybe you could have found it within an hour. And then put it, you know, found the issue if you were in Jarvis at point you directly to the area and the software and you basically could see within the assembly snippet that Jarvis provided that it was basically. You know, an issue a backdoor it was super quick to find so probably it's an hour so what if you were just randomly taking a binary and loaded it into a disassembler and manually going through the binary so that could be weeks to months depending on how much time you spend and how obvious the the actual backdoor is so it just depends. You know, case by case basis but that's kind of the magnitude of scale difference so that would be, you know, how do you go from tier one to tier three on that pyramid. This is kind of the process right you would run these tools figure out where your issue could be and then you jump right into the if you need to the disassembler and figure out where your issues are. So what about if we wanted to execute these and we didn't have source code and we wanted to maybe fuzz these things. Is that possible, like if you have a binary for an embedded spacecraft is, could you just run it without, you know, having the source code. So, you know, there is capability out there to do embedded simulation. But there's a lot of, you know, peripherals and things that probably need to be there, especially for a spacecraft because there's probably the things on the bus. There's various cards that need to be there, or it won't run. So it's not as easy as in the windows world where you can just, you know, it know the software was coded to run on windows or Linux. It kind of knows that architecture really well and just runs. We don't have that same luxury on the spacecraft, at least yet. So there are some known capabilities out there. There's he move. That's really great. It's free and open source. There's our Tim's. If you're running, you know, and our Tim's executable if you're running that our Tim's real time operating system, you can use their our Tim's run thing that they've they've put out. There's a emulator from the Koreans. There's Aerospace Research Institute of Laysim where they have some specialized support, especially for some spark processors because they do the Leon Leon three Leon four in their in their environment. So there's a pretty good product out there that they have that's free that you can it's not open source but you can get access to it for free using a free license. And then there's the Cots product semics. That's probably the most robust and has been used for at least 10 years at NASA, doing these high fidelity simulations. The problem is, is it's, you got to have a lot of the information so is it possible to build a full black box simulation of a spacecraft binary. It's really possible. You know, across the board it's pretty expensive so it's it's it's teetering on the impossible, but it's not quite impossible so it's very, very expensive time consuming. If it's super complex spacecraft architecture which most of our things probably would be if it's maybe not so unique and there's probably been some reuse of some commercial buses or things that are well known. It would be a lot probably easier to do it, but you know when you're doing looking at a spacecraft black box simulation. You know there's a lot of components to it that you would need to look into so not fully impossible because I guess nothing's technically impossible but it would be extremely expensive to do a black box simulation. You know so much about the software to be able to actually dynamically execute it so you know the architecture which is somewhat easy to derive but you need to know all the peripherals and interactions between the back plane and all the different pieces of the spacecraft which is part of the if you have the design documentation but you just didn't have the white software, you could probably get there but if you don't have that this will be even tougher. And so you know you made to do fuzzing you may need some sort of full execution environment and you may not be able to do it so and black box buzzing like I said is is little early on in the embedded world at least from the research that I found it's Heather some capability out there but it is rather time consuming to build those harnesses and especially you don't know a lot about the binary so I would say that's not a viable use case unless you have a full execution environment that you can do the fuzzing. So some takeaways and some summaries. So if we're wanting to perform some level of software assurance without source code and you know kind of very similar to static code analysis. Then we kind of can live on this this tier to scale. That's the tier on this page so long story short is there's no one tool there's no set it forget it. There's nothing you can really do from that perspective but there are tools that can help you get to that point interpreting the results is going to take you some specialized knowledge. So if if we can curate that specialized knowledge and only use when necessary and focus on developing these tool sets these automation pipelines to help out with this. You know tier one tier two that would be very helpful and you know we're starting to see some tools emerge to help buzzing and do black box buzzing but they're not quite there yet and a lot of that focus has been on the. A lot of that focus has been on x86 and not on the embedded side. So you know what's the summary of all this if you're looking to do software assurance without having access to source code if you're strictly focused on embedded and garbage is probably your best solution if you're peering between the the windows Linux as well and you may want to have something like code sonar and then have something like get your on hand to do some deep dives. So that's kind of the summary of what that would what the results of this research will be because we found a lot of good results on various tools but the embedded side Jarvis did stand out to us. So that includes the presentation. I appreciate your time and contact me if you have any questions brandon.bailey at arrow.org. Thank you so much.