 Hello, this is Reza Swisabi and with my colleague, Chuck McCauley, we would like to present our novel covered communication scheme that explodes broadcast signals in LTE 5G and other technologies. I would like to first give a little introduction about ourselves. The application research team lead at Keysight ATI Research Center. I do open research on 5G RAN security and develop algorithms to both make or break awesome things. I come from math and signal processing background, so I try to apply them to new problems as much as I can, and typically I happen to be at the right time and in the right place. So I have been breaking things and triggering rare events for fun when I become a dad, and now I love spending time with my toddler son. So I would like to turn to my colleague, Chuck. Hi, I'm Chuck McCauley. I'm a principal security researcher at the ATI Research Center at Keysight. My hobbies include skiing and breaking my land Rover and fixing it pretty frequently. At Keysight, I'm involved in new product initiatives and bring a long 20-year cybersecurity background to everything Keysight works on and touches. I really would like to expand on the ambitions and the thoughts behind this research, to encourage future research. I believe this is as important as the research I'm presenting here. As my father always put it, talking about fishing is more important than talking about fish itself. So I had some past academic research experience in wireless security. I published my work on IoT security in IEEE in the past. So most of my work was deep in theories and math. So I decided joining industry to explore more practical problems out there, and I was offering R&D consulting services to mobile operators and was a 5G system engineer a while before joining Keysight in 2018. Without being officially in infosec, I always had the tendency to break things around for fun and curiosity. So my new job at ATI enabled me to explore new ideas that are known in wireless community, most notably protocol tunneling techniques that are used for data exaltation. I was converging kind of my past and present experiences that one day in fall 2019 or cool bus, I invited me to take a lead in a 5G security research project and got me a lab with a super expensive baseband emulator in there. So with that level of trust that he vested in me, I decided to go after an all-day vulnerability discovery other than simulating existing ones. So I discovered this vulnerability in 5G and LG standards the following winter and we successfully disclosed it with GSMA. Things kind of went slow due to pandemic and my parenting leave, but after watching this interesting talk in last year DEF CON on eavesdropping satellite signals, I got really excited and pumped to put this work together and present it for DEF CON this year. I took a holistic approach of organizing the existing work in the biggest possible picture or call it a box and then discovered a hole in it. So I realized that covered communication is the biggest umbrella that I can put all techniques for data exfiltration, command and control and other means of communications, unauthorized communications are together in it. So it usually regarded as a potential threat and taken seriously in the context of defense in depth. When I serve a literature related to covered communication or topics related to it, I realized there are two dominant viewpoints that are coming either from hackers or wireless engineers. So people with hacker mentality, like Jack, have targeted software protocol stack most of the time. So like message tunneling in L3 to 7 protocols such as ICMP, DNS and et cetera, a lot of cool techniques there. They have barely looked below IP layer, in fact. As we know it, the security industry has actively been monitoring the research in this area. So they track and block malicious IP traffic using boxes like IPSs, IDSS and lawful intercept. On the other hand, wireless engineers such as myself are really fascinated with the beauty of radio systems, internals and physical layer. So there is a huge literature on coding and modulation techniques to build optimal radios for covered communication. These techniques usually involve low-power communication and avoiding spectral monitoring systems. So devices such as like Loravan, Hamradios and other low-power technologies can be kind of retrofitted and used for covered communication. But their operational range dramatically degrades when both sender and the receivers are at low altitudes. Where the signal in fact is blocked by buildings and foliage. Looking at the protocol stack, I thought of a new viewpoint, come up with a new viewpoint that combines both mentalities. So I come up with this question, how about exploiting the Mac layer protocol weakness in existing wireless infrastructure? This was the big question that inspired this work. It leads us to a new scheme that can be more effective than existing ones in many aspects. At this point, I was almost certain that I can find some simple example quickly in LT and 5G standards because I was very familiar with them. So very related to the theme of DEF CON 29, I developed a framework to exploit the unestoppable signals from cellular base stations that are everywhere. So height is what makes the RF signals unestoppable and operators spend big money to mount antennas on tall com towers. Or recently, some companies are trying to apply them on lower bidding satellites. And this is all about getting more and more coverage to as many users as possible. So let's look at this scenario that we're gonna be using moving forward. So Trudy has intruded a secure air gap building with a programmable device. So she would like to send a message to her friend Ricky with a passive snipping device sitting somewhere a few miles away. Like these anime geeks that we have down below this frame in the picture. There is no radio signal path between them due to buildings and foliage. So however, both can send and receive signal from a nearby cellular tower. So what if Trudy send a special low power obliq signal that triggers high power broadcast signals from the tower that then are received and decoded by Ricky. So simple, right? So this will create a virtual covert communication channel between Trudy and Ricky. And this is basically the description of the technique that we are going to present here. Putting it simple and memorable for you, we are creating in fact a reflection that are observable everywhere around the cellular tower. That's the key idea. So think of a Batman movie. They did not know where Batman is, right? So they were reflecting this light beam of the sky to make it visible everywhere so that they can see. So I would like to go and start talking about the example that I discovered in LTE and 5G standard. So let's take a look at the importable stack. What is the Mac layer? What does that mean, exploiting Mac layer? So in protocol stack, some initialization or handshake steps always happen within each layer before it starts responding to data from the upper layers. This is how protocol stacks crank up always from bottom to the top. So this work is related to the layer two in OSI model, often called the Mac layer. And from operating system perspective, this layer is whatever layer that enables devices to send IP packets so they don't care what happens in it. They just look at it as an interface or gateway to send IP packets. In order to understand what we are talking about today, it helps to understand the analogous version of what happens when you connect Ethernet cable to a switch. Right when you plug in your cable before you get a green light on your switch indicating your link, speed, and duplicate sync, a protocol negotiation has already taken place. The radio signals have synced up and found a signal in both directions. So there are some messages such as like a RAID auto negotiation that happened very early that people normally do not care about them or observing them in their packet captures. So let's now talk about the LT and 5G Big Mac layers. Something more delicious, right? So this Harry, our man is searching for signal in the middle of nowhere. So when he finally gets a signal before he's allowed to send a selfie to an Instagram about his situation, it tries to attach to a cell tower, right? And see if it allows to access it that mostly involves SIM card, voodoo stuff. The apps running on his phone only care about sending IP packets to the internet, right? So the apps do not care about whether it is WiFi or LTE or what happens inside these protocols, neither. So they see all these voodoo stuffs happening below IP layer as a big Mac layer. That's what they call it, the Big Mac. They do not care what's in it, they just enjoy using it or what it delivers. The commercial wireless infrastructure has many components such as cell towers and a bunch of core network servers whose job is managing millions of users across a wide area. This Big Mac layer that we're talking about in cellular standards has several soft layer protocols in it like a Big Mac, right? They define the interaction of user device with various components of the operator's network but not the internet. So this is Big Mac is called control plane as well or sometimes the people who built this network, they call them layer two and three. In the context of LTE and 5G in particular related to our talk today, the standards are made by a global organization called 3GPP for your information. It uses a protocol known as the RRCO radio resource controller, which is an access protocol that is the toughest layer of this Big Mac or you can call it the bun layer, that works more like a radius or messages in it looks more like a SNMP. But this is not what this talk about today. This talk today about is the link establishment for RRC protocol, the very initial Mac layer handshake that happens very early on before establishing an RRC connection. This is what this call is about. Think of it like a handshake between a phone and a cell tower before all other handshakes. And it has some interesting features to it that we're going to explore. And in fact, it does not travel to the operator's core network making it suitable for covert communication. Some simple terminology notes in here. So essentially in the context of LTE and 5G we call all the devices that interact with the cell towers, UE or user equipment whether it has a SIM card or doesn't have a SIM card doesn't matter. And there is another more important terminology notes that I'm going to talk about here is that the story of a node B. So in LTE they call these cell towers or base stations E node B in 5G. They start calling them G node B. And actually when I was talking about 5G with Chuck Chuck said that what happened to the F node B and I said interesting nobody uses F node B. So I decided to use F node B here throughout our following presentation to refer to both LTE and 5G. So random access procedure is a common functionality in wireless Mac layers. So there is a small set of signals called RATCH that are reserved for the UEs connecting to an F node B for the first time. See F node B. All the F node Bs respond to the signals regardless of device type or identity even if it doesn't have a SIM card. The diagram here shows the normal RRC connection procedure. There are four plain text messages exchanged between the UE and the F node B before the UE creates an authenticated session with the core network. These messages serve similar purpose to the Ethernet auto negotiation handshake which is setting up synchronization. First UE randomly sends a scramble signal from the RATCH set and then F node B responds with more RRF parameters that helps the UE to fine tune its framing synchronization. But these are not the important ones. The important ones are the message three and four. They enable the F node B to resolve resource contentions between UEs that are simultaneously attempting RATCH. Per standard, the UE should send a 48-bit string that contains a 40-bit random ID in it. Then wait for the F node B to broadcast message four. This string is called CRI or Contention Resolution Identity. If the F node B replies with the same string in message four, it means that the UE can proceed with the RRC connection. Otherwise, it knows that someone else is supposed to go ahead and this one has to stay and retry later. I think probably by now you've guessed what's wrong with this broadcast ping pong with the message three and message four. So coming to the Trudy and Ricky's covered communication scenario, Trudy and Ricky can have prior agreement under target F node B and Trudy's RATCH signal selection. Then Ricky is passively scanning and decoding message two and four from the F node B using its low power radio. Instead of including random 40-bit identity in CRI, Trudy can encode a short message in it and sending it up in message three. This message can include a signature byte, indicate that it is made by her, not by other users in the cell. Then Ricky can pick up and decode the same message from the F node B's message for broadcast that happens immediately after. Simple, right? This is a kind of like an illustration for the unidirectional channel, but essentially Ricky can repeat the same procedure to establish a reverse link to Trudy to kind of send information like acknowledgement. Looking at the history of this procedure, we believe that this vulnerability may exist in other wireless MAC layers as well. This particular example has been in LT and 5G for over a decade, but no worries. I will share at the remediation before these talk ends. So, exploiting a little bit, expanding on how, what they can gain by using Sparrow. Sparrow UI can break long messages into chunks of 40-bit messages and send them in multiple Ratch attempts. Succesive Ratch attempts do not have much impact on other users in the cell. And there is a back-off also timer that's built into the standard document. As you can see the snapshot right below, that the UIs have to basically pick up a random value as a back-off timer, but it's all been left to the user's discretion and the E-NodeBs or F-NodeBs do not have any way to enforce it. So picking the back-off time like a 10 milliseconds, usually the message one to four exchange takes on average up to like a 30 milliseconds. So in total, this can give Trudy one kilo BPS throughput link to reach messages to Ricky. Very limited, but it's still comparable to other low-power technologies like Lora. Outdoor LT and 5G base stations operating at lower frequency bands, particularly below two gigahertz, are more suitable for Sparrow technique, mainly because their signal can reach up to five miles and also they can reach indoors very well. 5G new radio, and you'll reduce some new frequency bands above six gigahertz that they involve lots of out-of-wood stuff like beamforming that making it difficult for Ricky and his fellas down below to decode and broadcast his signals. There is also a new satellite-based 5G standard called 5G NTN, which is in development. That might actually give the Sparrow UIs 10 times more mileage. Hopefully we can get our remediation built as a secure Ratch option for that stand. Also, benefits of using the Sparrow are really great. So you can get really super stealthy with it. No network footprint because messages are low-call to the FNOTB and nobody is going to log the Mac layer messages at the edge of their network. Also, the Sparrow UI activity is indistinguishable from the other UIs, so no radio spectrum footprint that's going to be there for external passive monitoring systems to geolocate the transmitter. These are the reason I call them Sparrow's. So no need for expensive equipment, right? So 100 bucks low-power SDR can do the job. They can also leave off rechargeable batteries or solar power. No need for high-gain antennas since they get the rebroadcast power from the FNOTBs, right? I will also show some more range expansion techniques further in the presentation. So they can get higher range per RF wattage in a cluttered environment. And that's a very key point compared to the other complex commercial radios like Wacky Talky or Laura. Who cares about the Sparrow's? I mean, really there are Sparrow birds everywhere. They're among us, right? Nobody cares about them. I know historically, sometimes they cared about them for crops, but nobody cares about them. And this is the same with the Sparrow with regards to cellular operators because they do not see any immediate impact on their network. So they do not care about it. And as a matter of fact, any temporary solution to block the Sparrow's kind of lead to some performance degradation to real users and we'll talk about that. But the remediation is that we've developed has to go be implemented at the standard level. So far, Sparrow's are unstoppable. So here, I'm going to actually turn the presentation to my colleague, Chuck, to talk about our demo and show the demo and also talk more about the use cases for Sparrow. Chuck. Thank you, Reza. So one of the benefits of working at an organization like Keysight is we get to play with a lot of cool tools. Even though we were in the middle of a pandemic, we were able to work with a lot of our peers in different parts of the world and we're able to convince the GSMA that we'd actually found a design flaw in the Ratch contention messaging structure. So what you see here is our demo lab that got set up for us by our peers in Italy. At the bottom, you see something that we call a UXM. Now this device allows us to emulate a E node B, a G node B, and hopefully in the future, even an F node B. And what you can do with this device is emulate a cell phone tower effectively and at the top, you see what we call UE SIEM which simulates whatever's going to connect to a mobile network and allows you to play with the messaging structure and validate a F node B or G node B or E node B, right? But what you can do is if you take both of these two test validation systems, you can put them together and build effectively a cell network in isolation and test out some theories. In the lower right-hand corner, you can see sort of a screenshot here of our test script that enables our UXM to pretend to be a E node B doing the Ratch contention messages. And in our next slide, well, not really a slide, in the next video that's coming up right here, we're going to introduce our friend, Befacuda. Befacuda works out of Italy and he has put together a quick video demonstrating Sparrow working for us that we then presented to the GSMA. My name is Bofgaro Dabur. I'm an application engineer at Keyside Technologies. In this video, I am going to demonstrate the proof of concept for the Sparrow project. With this Hermodic Graphical User Interface, we configure UE on ELSUA that's with an IP address of 1048870 as a TX. Therefore, we set the mode as a TX and the random access parameter ID 28. And the plain text message to be sniffed by the receiver UE is set to welcome to the DEF CONF. Similarly, we have set the UEB on ELSUB with an IP address of 10488157 as an RX. Therefore, we set the mode to RX and the random access parameter ID 28. On the current worksite, the priority script activated the 5G NR standalone cell where the synchronization signal block is broadcasted via the eXM platform with a periodicity of 20 milliseconds. If the master information blocks is decoded with success on both UE so the cells will get synced and in service if the system information block type one is decoded. Since both UE are in service in sync and idle, we can connect the GUI to the Layer 3 Test Manager and verify if the CV is decoded then the cell should get in service. We can run the scenario from the RX site first now and from the TX site. It seems that the transmitted message is with success on from the TX site and let's verify if the receiver UE site decoded the message successfully. So from the scenario logger, here we are decoded that the message welcome to the DEF CONF France. From the TX site, it can be verified that the message two is decoded with a valid RAR. Also on the RX site, we can check. The message two is decoded with the valid RAR as of TXUE. This is the case we can also verify the message through three is decoded with success. First from the TX site. So here we can confirm that the UE Contention Resolution ID decoded with success on the TX site and let's see also on the RX site. So the RX site message three is also decoded with success. So since we have implemented a CRC decoding if the message is decoded, we can see the message on the RX site. So you can see the message is decoded successfully. Welcome to the DEF CONF. So there you saw a buffet showing us how you can bounce a message between two UE's across a cell phone tower, which is pretty wild. So let's talk about what you could do with this sort of technique. A lot of the applications are pretty obvious from the get go, but one that we thought was pretty neat to highlight would be the ability to exfiltrate data out of a secure site. There are cell phone towers that are doing these Ratch procedures all the time. So it'd be very hard for you to notice an additional Ratch procedure occurring with a cell site from a specific UE at a specific location. When you start thinking about the application layer and digging in the data in there, you can either have a service provider or a government entity intercept that communication layer and prevent it in multiple different paths, but at this low layer on the Mac layer, this is happening before any of those things occur. You could also use this to easily trigger events remotely like opening a door and more drastically triggering a bomb to occur. And you can be well within say five to 10 miles away from the site in the event that you're triggering, right? So that's a long distance to cover and figure out the source of the message. And lastly, this could also be part of a supply chain attack where you actually bake in some kind of remote control process into the device and then access it at a later date, right? Which is also a big risk these days with our vast and multiple country supply chains that occur. But there's also good applications for this that are used for good. If a tower loses its uplink to the rest of the data network, it still can provide some use whereas before it might have been just a thing that just sits there and waits until the connectivity is reestablished. So this could be used for broadcast messages in case of disaster or emergency. It could also be used to connect emergency personnel themselves to each other and tell them where help is needed or what needs to be done, which we think is a really neat application of this in general. And then lastly, we think that there's a lot of opportunities for mischief here instead of using lower WAN or other IoT based low bit rate protocols, you could use someone else's cell phone tower to provide the overlay network for your IoT devices and then simply have one device that picks up all the signals and transmits them on an internet uplink somewhere. You could also use this to help improve a pager network. This device here, this doesn't use it. This uses lower WAN right now, but it's made by natural Freck and he uses it to pass messages back between different devices at Shmoo and Defcon. You could easily hijack a cell phone tower and then instead of having a mile or two of distance or a giant ugly antenna, you could just be passing messages with something a lot smaller and a lot neater. And now I'm gonna bounce it back over to Reza who's gonna talk about increasing the signal boost and some remediation. So in the case of LT and 5G, the Sparrow UIs can exploit kind of like multiple F-node piece except the very rural areas. It is common for a Sparrow to have access to multiple LT or 5G carrier signals in any area within range of a few miles apart when the UIs are not that much far from each other. So this can help them to essentially establish catalog communication channels and enhance their throughput above like one KVPS that we estimated. Another cooler way actually to use multiple cells is really to expand the range beyond a single cell radius coverage like a beyond five miles. So for doing that, in fact, the Sparrow you would need to use Sparrow relays. So Sparrow relays are dropped basically where they can listen and transmit and interact with multiple cell towers. And their job is being rekey in one cell and being acting like Trudy in the other cell as you can see here. So Sparrow relays can be small, kind of like a solar powered devices that are dropped in random places. So to be more specific, LT cells are deployed in kind of like a hexagonal pattern to cover an area. So this picture that I'm going to show in the next slide is going to show how the relay nodes can be placed. As you can see in here, so you have a multiple ways in here to place them. So you can actually place many of them in where the actual sector coverage areas overlap and create a mesh network. So every node can talk to every other node and relay messages or you can actually create a specific chain to expand the range between two endpoints. But what is the remediation here? I mean, with all what we said here, what is the remediation? So let's just start before I get to the remediation. I think there is a value to learn in case what is the general weakness model that has enabled the Sparrow in LTE and 5G and potentially it can exist in other protocols. So I kind of spend some time and have formulated this and possibly I'm going to be publishing all this work following the DEF CON but to kind of give you a general idea about it, a wireless Mac layer protocol I found is vulnerable to a Sparrow technique. If any of these procedures allow forming two sets of uplink messages that I call M and a downlink broadcast message I call in B that satisfy the following conditions. So the first one is a passive reception. So every signal in B or should be receivable and decoded everywhere. So it should be kind of like an omnidirectional broadcast that any passive device anonymously can decode it. Another key feature is basically we call it by activity but it's a one-to-one relation between them. So essentially if you have a set of 10 messages and each of them, each message B can only be triggered by a specific message that is in the set M. In other words, when a receiver receives B it can almost surely assume that its intended transmitter has transmitted a specific message. So that way they can have less error during their communication channel. Another one which is a key important thing but it's kind of like optional but it is a good important thing to have and we have it right now in the example that I showed you in a spiral is that anonymous uplink. So essentially the transmitting device doesn't have to attach to the network or authenticate to the network to be able to send those messages which actually we already constructed a message set which is actually the CRI and that for the beta strings that they can pick are going to form or superset for set of messages that they can transmit. Another key feature down here, number four is to bring a stateless uplink. It is important that the transmitter or Trudy can successively send any messages from M, set M without protocol violation as we talked about it sending successive messages and not caring about much about the backoff in between them. So all these four conditions together if they apply in any specific wireless microportical that means that some similar techniques to this spiral can be formed around it for covert communication. Any remediation to should preserve the purpose of CRI. So why we have this here, why we have that selective message three, message four, ping-pong. So as you can see, it's for contention resolution. So there's more details about that. So let's assume that two of these are picking up the same Ratch signals to attempt to innovate. So essentially at this point, E node B doesn't know there are two messages coming because of the properties of the Ratch signal, only one of them is going to make it to the E node B. So E node B is going to send additional basically fine tuning parameters for one of them. And but the point is the message two, both of them are going to receive message two. So at this point, both of them think that they are succeeding. So at that's the point that F node B actually has to have a way to signal only one UE to proceed and the rest of them to back off. And that's the point that it requires every UE to send a 48 bit CRI message. So, and then it's just going to rebroadcast the one that it has received. That is going to surely indicate that one UE is going to know it can succeed and the rest of the UEs are going to basically back off and retry. So before I get into the solution that works, I know maybe some of you already are thinking about some solution ideas. So let's talk about them and talk about why they do not work. So what about like pre-setting CRI phone? Why the phones have to randomly select them? What if we hard code all the phones to like make it like a Mac address? So they have to use the same thing. There are actually some privacy concerns with that. There are already attacks in LT and 5G on privacy and we have lots of techniques for catching people phone numbers and MZ. So any tying up, any fixed identity that can be broadcasted everywhere that can lead to privacy issues for the users. So this is not like a Wi-Fi which is a local network. It is a global network. Another one is shared secret note. There is no shared secret between the UN if not be at this point because all the cell towers are required to do this interaction with devices even they don't have any identity or SIM card. So what about like a crypto hashing and salting, right? That's a to-go thing, crypto, the fun stuff. That in fact doesn't work because first of all, if you think about message three and message four broadcast, if the F not be tries to basically hash what it puts in the message four so that the designated UE can just check the hash or we compute the hash and compare them, proceed and the rest of them are going to back off. It has to basically, even if it starts like using like a salting technique down here with hash some most sophisticated way to put even if it is using salting, it has to ship the salt string with the hash all together. But does it really prevent Ricky and Trudy from exchanging messages? Not that much. It just makes adds a little bit computational complexity to the mix. But in fact, the Ricky can still recompute because it's going to have the hashing algorithm is going to have the salt and it's going to be able to compute these values for any set of known code book messages that they decide to use and they can just stick to that code book. So it can slightly slow them down but it's not going to solve the bigger problem. Also, the F not be cannot distinguish between the Trudy and the other users. So any attempt to blocking some of the signals if they repeat successively, it is going to have a performance impact. So the actual users have to pay the cost. And as I've mentioned before, the operators are reluctant to take such necessary steps. So what is the real solution? This is the solution I put together to be proposed to the standards or the remediation has to come to the standard level which actually might have applications in other field. I call it like a extensible loss induced security hashing algorithm. What it does is just adding one layer of entropy over that salt thing and hashing that we were talking about it. The first few steps are very similar. So we do some salting. So once the F not be receives a message three is going to apply salting and apply the crypto hash. Right there, I kind of come up with a new salting algorithm called random multiplicative salting. It's a kind of new algorithm that helps reduce the collision probability when you're using crypto hash functions with shorter strings like CRI. And then after that, it starts applying some random erasure to the output of the hash function. So it decides to not transmit all the bits that come from the hash digest but send randomly select a bunch of them and send them out in message four so that the intended you can, you know essentially has to have all the information to repeat the same process and compare the output. And if it matches, it can process if it doesn't match as it has to back up. So that means that the salt in addition to the salt we have to also ship a basically a bit of string that indicates that which bits we have selected and which bits we have not selected from the output of the crypto hash all together to the UE. So that's what I call it bit mask. As you can see in this case there are two advantages to this that makes it impossible for Trudy and Ricky to communicate. First of all, they were reconstructing like a rainbow tables and recomputing the hash for their code book. But the point is that layer of the erasure that we put in between they cannot create a code book that both can be recomputed by a hashing algorithm at the same time have error correcting feature and capabilities in it. So that kind of that having enabling those erasures and errors in there in their communication is going to totally reduce their chance to correct those errors. So that way their whole communication scheme is going to fall apart. Another key point in here to mention is about the cost, right? I mean, always there is no free launch out there. So that's the whole point in engineering is that whenever we're trying to improve thing we have to pay the cost but is it the cost we are paying is the right cost. In this case, as you can see, significantly increase the number of the bits we are replying in the message for in stuff like playing by 48 bits. So in the example of like a MD5 hash instead of playing back 48 bits we might be playing back about like a 200 bits. But that's not a problem with LTM 5G and the amount of like the bandwidth and resources that are available for this. This is not going to be a big cost to pay really for preventing this. So as a matter of fact, what we are proposing here is going to be more of an optional secure latch. So it doesn't have to be implemented everywhere across the network but maybe the operators want to implement this near some critical facilities and areas where they're requested to do so. So I would like to kind of get to the wrap up points in here. So I'm going to turn quick to Chuck to share his concluding bits about the story and he's been all along observing me working through this. So I would like to also share him to share his feedback with you. Chuck. Thank you, Reza. When Reza came to me and he talked about I think I figured something out in the Mac layer and we can like smuggle messages in and out of a cell phone network. I was like, no, there's no way. Mac layers are boring. You know, the best way you can do with anything like that is, you know, get from port one to port two on a switch. But just because it's layer two doesn't mean that it's localized. And I think that's something that I really sort of took away from all of this. We also really don't think that LTE and 5G are the only systems that are vulnerable to these types of attacks. If you just start digging around some of the Mac layer protocols that are used by satellites, there seem to be about 10 to 20 of them. And that would give you a lot farther reach than anything that's terrestrial based. There's a whole host of other radio broadcast signals out there as well. Formato 211 to Bluetooth to lower ran to other things that can probably be abused in similar fashions. Also, just to note, LTE and 5G is now for everyone. With a budget of about the same as a gaming computer, you can buy enough equipment now to build your own LTE network and even the FCC's granted spectrum for you to go and play around with it in your own sort of private space, which is pretty wild. So yeah, we'd like to also say thank you to many people in our team, including Befe and Luca, and Resid would like to say thank you to a few others too. Yes, thanks Chuck. I think I'm going to thank Chuck for all the work and support that he offered me during the CFP process and putting all this talk together. Also, the ATI management staff, Chris, Steve McGregory, the cool boss I mentioned early on that who kind of like inspired me to go through this all day discovery. Also, I would like to thank for a Keysight IB program coordinator, Pete Marisco, that he did a great job of sticking to a very fast timeline so that I can share the remediation bits here with you to him. And in general, I really thank Defcon. It's been a really great experience for me. I really love to continue being engaged in the community. Thank you.