 This talk is going to be about a software platform that we wrote to enable fuzzing RF protocols. Uh, my name is Matt Knight. Uh, I'm a senior security engineer at Cruise Automation. Um, we are hiring. If you're interested in, uh, working with us, come find me after. Uh, I also lead the RF practice at Riverloop Security, which is a, um, uh, embedded, uh, embedded security, uh, consultancy. Uh, if you go back far enough, I got a bachelor's in electrical engineering from Dartmouth and, uh, pretty much everything I've done since then has been all about, like, embedded systems and software defined radio. Uh, that's me. And hi, I'm Ryan Spears. I'm the co-founder at Riverloop Security that, as Matt said, does embedded vulnerability in RF, uh, consulting. I also lead research at Ionic Security. I guess I'll claim we are also all hiring. Um, my background's in computer science, but my focus after that's been in applied cryptography, embedded systems, special passion for IEEE 802-15-4 or ZIGB, uh, and doing automated firmware analysis. Cool. So we're going to begin, uh, this talk in a little bit of a non-traditional way. We're actually going to kick this off with a, uh, a demo. And then we're going to talk about what we're watching here, um, through the rest of the talk. This will just take about 15 minutes. So when, when Ryan and I were, uh, were conceptualizing this research, we, we were thinking what could be the most boring demo to possibly show on stage at DEF CON? And we thought that live, it really can't get much worse than live fuzzing. Uh, but that's what we're going to be talking about. So we're going to come back to that. The, uh, the background for this talk, and I wanted to do that for like another five minutes, but he said no. Um, so the, the background, a few things that you might be interested in, um, the, some of the research here, builds on research we did in making and breaking a wireless intrusion detection system, uh, which myself and Javier presented at Troopers, as well as an ACM paper about speaking, uh, the local dialect, which was about idiosyncrasy, idiosyncrasies in FiLayer or Layer 1 implementations of, uh, fuzzing. So today we're going to talk about how we can use these for not just, use the fuzzing to do bug discovery, uh, but also to figure out differences about the physical layer, uh, finite state machine, and then generating fingerprints to identify chips differently based on that. Cool. So we're going to kick off with an overview of, uh, traditional fuzzing, kind of fuzzing is, I think most of us know it. Uh, we're also going to comment on how those don't easily map to RF and kind of the motivations between writing the tool Tumblr app we'll talk about later on. Uh, we'll talk about some of the design principles that went into it, uh, and then finally we'll, um, we'll, we'll, uh, come back to that example we showed, kind of showed the significance of it, uh, and then we're going to wrap up the ruminations on hardware and, uh, where we want to go with this research, uh, to enable fuzzing arbitrary wireless protocols. Sure. So going through, and I think most people know, uh, or have some background in this, so we'll go through relatively quickly. Uh, fuzzing is applying pseudo random input into the system. The goal is to automate discovery of crashes, corner cases, bugs, et cetera. We're feeding in unexpected input, uh, and trying to find out if we can get the system in unexpected state. So overall, uh, people typically attach fuzzers to system interfaces, input output, injecting into, like, uh, to, to feed files, uh, to see if a file format parser works correctly, to feed bad or malformed data into network interfaces, uh, or to play around with the memory state of a machine. Um, and for software, there's a lot of really great tools out there, right? Uh, AFL, um, which is a pretty advanced tool that uses memory introspection to help, uh, advance its, its, uh, state coverage. Peach fuzzer, which although is a legacy tool is still, still used today. Uh, and Scapi, which is a network protocol generator, but also has some, uh, basic fuzzing in it. Now, what's interesting with software is you can instrument and hook it at many levels. You can control typically when it starts execution, when it finishes, monitor the state, monitor the state through hooks or memory execution, but what else can one fuzz? Cool. So we're briefly going to run through some other applications of fuzzing. Um, so fuzzing hardware is something that's been done in a couple different, uh, uh, through a couple different approaches. The challenge is that, uh, hardware, with hardware, the interface is often a lot less trivial, uh, to monitor than it is in software, where you control execution, where you have, uh, easy ability to kind of attach that interface. Uh, so it may not be easy to get a harness that can hook into hardware and monitor its state. Um, but there are some, some pretty interesting, uh, uh, approaches that have been made here. For instance, AFL Unicorn, uh, which, uh, emulates, uh, firmware, uh, to fuzz, uh, that, uh, it needs three different pinouts to look for, um, in data rates to find digital buses on hardware. And also J-Tagulator, which does the same looking for unlock J-Tag. Uh, so those are kind of like fuzzing, um, like hardware interfaces to try to find pinouts and things like that. And there's some others too. When we talk about fuzzing RF, um, there are a couple different projects I want to comment on, um, just to kind of frame the state of the art. Uh, YFuzz is an open source project, uh, that's a layer two focused 802.11 fuzzer. Uh, again it's just focused on, on the MAC layer and, uh, it doesn't engage the PHY really at all. Um, it's also built pretty specifically for 802.11. So to take that and move it over to, uh, or extend it to support another wireless protocol would be non-trivial. Um, additionally are, uh, my former colleague Mark Newlin, what's up Mark? Um, when he was doing his, uh, Mousejack research, uh, two years ago, um, he used fuzzing as part of his methodology for, um, uh, for, uh, injecting packets at these, uh, NRF 24 hid dongles to find different, uh, uh, packet injections and wires, wireless messing keyboard protocols. Um, Mark, uh, chose not to open source his tools for that. Shame on you Mark. Shame. Shame. So we cannot, we cannot build on his great work. Um, and additionally, if we go back to Ryan's original, um, 802.15.4 file or fuzzing research, he wrote the isotope framework, um, which was a 802.15.4 fuzzer. Again that was also fairly protocol specific and not easy to extend. Shame. Shame. So, uh, kind of to tie that up, um, limitations of existing RF fuzzers is that they are generally siloed and protocol specific. Um, they might use a COTS radio chip set, um, that may or may not, uh, expose the PHY, uh, and they're, they're, um, g, and they're generally limited to like a single protocol, um, because they're built with certain features in mind. Additionally, as with hardware, RF state is pretty challenging to instrument. You know, it's really hard to measure what constitutes a crash or some sort of a weird behavior, uh, in, in, in a, uh, an RF protocol, whether it's, you know, like a traditional like layer two approach or if you're trying to, um, identify behavior on the PHY. Um, additionally, you know, if we're using a COTS radio chip set, we're kind of forced to trust what it's giving us. Um, we don't have a lot of, uh, visibility into the execution of what's actually happening on the PHY chip. So that's part of what we're trying to expose with this research. Because, uh, there's an interesting characteristic here, um, and that's that not all PHY state machines are created equally. Um, and I'm just going to, going to share some ruminations on, on standards and kind of how they come to be briefly just to frame this. So if a industry group decides that they want a standard, say, uh, your power company decides that 802.15.4 isn't sufficient for doing wireless meter, meter reading any, any more and they want something new. They all get together in a room with a whole bunch of stakeholders. Uh, they spend years talking about it. They decide what they want to be in the standard and then they turn that into a nice, uh, easy to read 5,000 page document. Um, that may or may not be freely available. You may have to buy it. They might make it available. Um, but anyway, different manufacturers get the standard, they take it home and then they have to interpret it and turn those interpretations into, uh, into a chip. They have to take that and turn that into something that actually works. And as you might imagine, even the most, uh, well formed, uh, closed, comprehensively defined standard is still going to leave room for interpretation and there's still going to be differences in these implementations that we can, uh, that we can, um, monitor and begin to, uh, instrument off of. Uh, some of these differences can be pretty profound and can be exploited, um, as the initial 802.11 research showed. Um, so we're gonna, um, show how these fuzzing methodologies can be applied to RFIs to, um, expose different corner cases in, in, in these protocols. Before we do that, uh, we're just gonna share a brief primer on how radio frequency communications actually work and this is gonna be very, very high level. So we're talking about radios here and radios are devices that take ones and zeros and translate them into electromagnetic energy for the purpose of, of transmitting them over some distance, some air gap distance. And they do the inverse too. So when we're talking about transmitting, we're going from ones and zeros into electromagnetic energy. We're talking about receiving, we're taking, uh, electromagnetic energy and going back into ones and zeros. And the hardest part with building a receiver has to do with sam, sampling and synchronizing on, uh, the, the, the energy state that, uh, that represents the signal. So, uh, I have just a picture we're gonna talk about briefly. Um, does anybody in the audience know what this is? Uh, yeah, I heard Bodline, so, um, that's the name of the tool. But this is a, um, a representation of a spectrogram. So what we have here is we have time in the x-axis, frequency in the y-axis and then power in the z-axis. So we're looking to signal here. And, uh, we're just gonna talk briefly about what's here. Um, we've got a, a periodic pattern that repeats in the beginning. It's a preamble. And that's just an alternating, uh, uh, sequence that tells the receiver, hey, I'm about to receive a packet. And it also tells the receiver some information about the clock of the transmitters that it can do some synchronization. At the end of the preamble, uh, there's an element called a start-of-frame delimiter. And what that is, is that's a, a discontinuity from the preamble, um, that is a magic number. So, the receivers know to look for this start-of-frame delimiter. And when it sees it, it's gonna say, okay, I'm done receiving the preamble, I'm gonna lock on to this and just start reading out bits. And that represents the rest of the, rest of the data. So the preamble is kind of the training sequence. The start-of-frame delimiter marks the end of it, and then the data follows. So we can boil, uh, a rough abstraction of an RF state machine down to look something like this. Um, where when the radio chipset is in its idle state, it's looping over the seeking preamble state. Uh, when it sees that it's receiving a preamble, it moves on to the, uh, seeking SFD state. If it receives an SFD, it basically starts reading out data for some, some, uh, some number of bits before presenting that up to, uh, the layer 2, uh, layer 2 parser in some way. So we're gonna dig into these two states and talk about, um, to kind of frame, uh, physical layer fuzzing. So the way these two states work is they essentially, uh, run a correlation operation across, uh, the symbols that are being received from the, from the demodulator. So this correlation is basically a shift register that's clocking demodulated bits through at the symbol rate while it's looking for a pattern. Um, so when we're looking for the preamble, we're looking for that alternating sequence of zeros and ones, that zero one, zero one, zero one. And when we get a good enough match, then we can say with confidence, we've received a preamble, we're about to receive a packet. Let's go to the next state and start looking for the SFD. And that's a very similar operation, although instead of looking for that zero one, zero one, we're looking for whatever the magic number of that protocol is. So just to kind of illustrate this briefly, um, talk about this, this table here. Um, so on top we have, um, RF symbol values that would be clocked through the shift register. And then beneath it, in the preamble correlation value row, is the magic number that our physical layer, uh, standard is looking for here. Uh, a pretty standard, um, implementation here is just to have that alternating zero one, zero one pattern. So what this correlator is going to do is it's going to XOR the current state, uh, the current symbol value state against that, that magic number that we're looking for. And then it's going to compute the hamming distance of that result. And the hamming distance is essentially the number of bits that are set. And it basically represents the number of bits that differ between the current state and the value that we're looking for. So if we're looking for things to match really well, we're looking for that hamming distance to be zero or very, very close to zero. So if say we had an arbitrary packet on the air, and we're clocking these values through, zero one, zero one, zero one, you can see the hamming distance changes, it goes up and down, until finally, we've loaded the preamble into the shift register and we can say with confidence, alright, uh, these two strings match, or match below a certain threshold, we think we're receiving a, um, a packet, we're going to move into the next state. Uh, so we do the same thing with the SFD state machine, don't have to illustrate it, the only difference here is that rather than looking for zero one, zero one, we're looking for that magic number. Well, it turns out, as Ryan's research, uh, a couple of years ago discovered, um, not all of these sync words and preambles are implemented, uh, they're not all implemented the same way across manufacturers. Uh, so, certain chip states were found to correlate on different, uh, preambles and sync words than others. So, that's really interesting because as attackers, if we're able to strategically malform, or, or leverage that, we can get radius to do really interesting things. So we can do things like send short preambles, send different sync words, and characterize how these different chip sets perform. And, uh, we can, uh, automate the discovery of this process by applying fuzzing. So with that, I'm going to head over to Ryan, and he's going to talk through, uh, the design of an R, ideal RF fuzzer. Exactly. So, what we set out to do is sort of think first about what were we not getting in existing techniques that either we were writing one off for clients or for projects or for research, and also what did we not find in some of the existing tools. Um, so these are sort of the four things that we wanted to come out of it. First of all, we wanted to be able to easily change out the RF interfaces, use different radios. This can be because we need to work on a different frequency, or because we want to work on a different protocol, uh, etc. Then we wanted to be, have flexibility in how we generated the test cases. Um, there's a lot of great tools, some of which we talked about earlier, that can generate fuzzing test cases. Some are generative, some are mutative. We wanted to be able to plug those different ones in, in a flexible way. Uh, and then reusable. And I think this was a main one for us. We had done this research on 802.15.4. Uh, we want to do some of this and port it over to other protocols. We'll talk some more about that at the end. Um, and then lastly, the comprehensive uh, alludes to the fact that we didn't want to just fuzz layer two and above, the MAC layer and forward. We also wanted to expose the FI layers so that we could tweak it and fuzz that. Uh, and that's something that is sort of unusual in, um, a lot of fuzzers. So out of that came something that we are releasing and talking about called Tumble RF. Tumble RF is a software framework for fuzzing arbitrary RF protocols. And there's sort of three things that it abstracts out. First of all, the radio API. Uh, second, how do we do the test case generation? And lastly, how do we, uh, what we call the harness, which I'll talk about more in a minute, is how do we instrument the state and monitor the state of the target. And so if we draw this up in a fancy architecture diagram, it looks like this. Uh, the sort of the middle of the test case management, command line interface and results logging are the things that we didn't want to keep rewriting every time we did this. Uh, then what we want to do is be able to change out the stuff on the top, the right or the bottom. Uh, the test case generator, uh, which creates sort of the byte patterns that we're going to send out on the radio. The harness which measures the state, um, of the target. And as the lightning bolt, which we all know is how RF looks, um, is how we transmit, right, from the bottom thing. And so we send lightning bolts across from the transmitter to the receiver. They wouldn't allow us to do the demo on stage for obvious safety reasons. I just want to say for the record, it does look like that if you shirt your PA out, but yeah, we, we have made lightning bolts at times, not on purpose. Um, so I'm going to step through each of the interfaces and the reason that I'm sort of going to go into the depth more than we may typically do is because we want you to understand that this is a simple, we hope, uh, easy, we hope, usable, we hope interface that you can take, modify and extend. So if you want to add a new radio, what you need to do is implement the, uh, interface. And to do this, uh, you basically inherit this class, it's python, um, and implement a few functions. Transmit, start receiving, stop receiving, you know, get radio frames. Um, and then we have a few set and gets. And this is to change the channel, but also some of the stuff if you have the ability on the interface you're working with, uh, to set the SFD or the preamble and that gets into some of the file layer fuzzing that we'll be using today. Uh, the next is the generators. This is how do we generate the fuzz, you know, the fuzzing input into the system that we're going to send out. Uh, the goal of this is to integrate between either something that you write in custom for protocol, or maybe you're tying into one of the fuzzers like peach or scappy that we talked about earlier. You have to implement two functions, one for the control case. It sends a frame, it should return a frame that is typical, standard, totally kosher as the, you know, as the standard specifies. And then the other is something that yields test cases. And this spits out the permuted input, the randomized, uh, input or wherever we're going to use to try to cause a bad state. In, uh, what we're showing today we're going to be using the preamble length generator, but we also implemented two others. Um, we'll show you the preamble length in a minute, uh, more illustrated. The other one is to put non- non-standard symbols in. So if the standard says this map pointed out earlier, zero one zero, one zero, one zero one, what if we start changing that? One one zero zero, one one zero zero, uh, and seeing what happens to the radios there. Uh, we also can put random payloads in the message as an example that this is not just applicable to filer fuzzing like we're focusing on today, but also fuzzing the macro application layers. And the last major of the classes that you can implement is the harness. The harness's job is to evaluate the device under test, uh, see if it's in a good state, bad state, or because this is important in embedded, uh, fuzzing, to reset it, get it back into a good state when we cause it to, uh, go haywire. And so we have different ways to do this. Today, uh, for simplicity we'll be using the received frame check. Basically, listening on a radio and saying, did I get a frame? Did I get a frame? Did I get a frame? And that works really well for filer fuzzing. Um, because you can know it's because of the filer and not because of some upper layer because we can configure other things out of there. Uh, but also if you're working against a real target, you often won't be able to do that. You may monitor it state by seeing if you get an acknowledgement frame back, if it acts your, uh, frame, or by monitoring processes to see if they crashed or looking at serial output to see if you have a serial console on your target, which we all know they like to leave. Um, then you can see if you're getting good output that, uh, indicates a good or bad state. Lastly, we tie this all together by implementing a test case. So this is what coordinates the, the generator, the interface, and the harness. This is typically very lightweight and we have some that are defaults and some that you can extend. Today we'll be using the, what we call the alternator case. Very straightforward. Send a good frame, see what happens. Send a fuzzing frame, see what happens. Good frame, fuzzing frame, etc. Uh, and the purpose for that is to just alternate between no and good states to see if we're still operational, uh, after injecting. Cool. So, uh, we're gonna show you a quick demo of, uh, TumblrF in, in action, uh, going after, um, some certain physical error characteristics in the 802.15.4 preamble. Er, sorry, 802.15.4 protocol. Uh, so this is what, uh, the test setup looked like. Um, we, we're gonna show a recorded video demo at Defconn's request. Um, so here's, here's a laptop that's running the TumblrF framework, um, just, uh, running it natively. Uh, and hooked up to it are a series of dev boards. So we have, um, three devices under test that we looked at. They're all 802.15.4 boards. Uh, from left to right we have this TI CC2420, uh, which is mounted on an API mode, which is a, uh, 802.15.4 test board that Ryan designed a couple years ago. Next to that we have a, uh, a dev board from TI that contains a TI CC2531, uh, which is essentially the updated version of the CC2420. And then right next to it plugged into the laptop that, um, small black dev board is an Atmel, um, uh, RZ USB stick, which has the AT86RF230 chip on there, which is another 802.15.4 chip. And, uh, today to conduct this test I'm gonna be injecting a stimulus signal from a USRB, USRP B210, which is just a software defined radio. Um, any software defined radio would work with this methodology. Um, so when we talk about our architecture here, uh, the three dev boards on top are going to rep, uh, are going to be tied into the framework via an RX interface within the harness. And then the TX interface injecting, uh, into the, uh, injecting into the, uh, um, into these devices is going to be the USRP software defined radio. All we had to do was extend, uh, the test case generator to, uh, enumerate the preambles. And, uh, and that's all that we had to do on the, the Tumblr F side to get this ready to go. So the case that we're gonna be looking at here, um, is, uh, the 802.15.4, uh, preamble. So the standard, uh, the 802.15.4 standard, um, stipulates that the, the fi header, uh, is comprised of three elements. Uh, the first is four octets of, um, hex zero valued bytes. Um, so we have, um, uh, four octets of zero that represents the preamble. Finally, or after that, the starter frame delimiter, um, is hex A7 in the standard. That's the magic number, uh, the magic number that the, um, that the receivers are all looking for to correlate against. And finally, that's followed by, um, one octet of length. Uh, it's actually only seven bits, but, but there's one unused bit in there. Um, but that follows it, that's in the standard. So what we're gonna do is we're gonna, um, experiment with the preamble length. So we're gonna see what happens as we begin to take away preamble octets as we, we send stimulus frames at these receivers to see what, what we can reveal. Um, so to generate this data, um, I'm actually using GNU radio. Um, since this is, it's a software defined radio, um, it's basically a blank canvas for us to do anything that we want, um, RFYs with it. Um, we could use a hardware defined radio if we had access to low level registers that allowed us to configure the, um, uh, to configure PHY characteristics, which the API mode does. Uh, but for simplicity and for, um, kind of mutability, software defined radio is a nice way to do this. Um, so I'm using the GR IEEE 802, 80254 out of tree module, which is written by a gentleman named Bastion. Um, he had a really nice job architecting it, so to cut out the PHY header, all I had to do was bypass that access prefixer block. Um, so what that, uh, what that block normally does is it depends the, the preamble is sort of for the limiter and the length. Um, when you bypass that, it doesn't do that, which means that I can then go upstream into TumbleRF and implement, uh, those values in software on the host. So it becomes super, super easy to iterate over, um, and, and it was, it was very easy to set this up. And then this is hooked into the radio API via TumbleRF, using, using a radio interface. So we're going to tap over and show a quick demo here. Uh, we'll pick up where we left off. Um, give us a moment to take a drink of water. Will you watch more thrilling live fuzzing? This was, uh, super, super brave of us to do a live video demo of fuzzing at TumbleCon. So thank you for, thank you for, for bearing with us here. Yeah. So, should wrap up in just a minute here and we'll be able to take a look at the results. So what's happening here is Ryan mentioned is we're running the alternator, uh, test case generator, um, sorry, the alternator, um, alternator case, um, uh, test case here. So what this is doing is this is injecting a, um, a control case, a standard 802.15.4 frame, uh, to make sure that the radio is in a known good state before injecting, uh, a test case. And the reason why we always send a control case before test case is if we want to run this thing and go to lunch, uh, and run it like 10,000 times, if it crashes on the 300th iteration, we don't want to have, you know, 9,000 false positives following it. We want to make sure that the radio is in a known, testable good state before we, uh, before we send data into it. So at the end, at the end of it, we can jump over, uh, use the part, parse results, um, script that we have to, to print it out, pretty print it, and then we can talk about it in the next slide. So we're gonna go back to the slides, but it'll have the same content, um, if you remember test case six and eight have interesting, uh, switch from valid versus invalid versus the rest. So if we look at this, um, do you want to drive? You want me to computer for you? Yes please. Okay. Cool. Um, so now what the output of that is, is in the upper right hand corner, um, it's actually from a different run, but it's about the same results. Um, we just ran over 50 iterations when we're actually doing this, we run much longer. Um, so one thing that I, you know, want you to take away from this one, we've added some color highlighting from the three different chips, uh, around here, is that you have three transceivers, three different chips, made by two different manufacturers, all implementing what should be is a single protocol, uh, but you have three behaviors coming out of that. Right. And so if we look for example between the CC2420 in the upper left, the one on the app emote, and the Atmel 86RF, uh, that we just showed you the video, thrilling video demo of, one thing that you'll notice for example is that test case two and four are received most of the time, uh, on the CC2420, but they are received none of the time on the Atmel. And even between the two chips by the same vendor, by Texas Instruments, on the left-hand side, you do see differences, especially around test case two, in the amount, and when we break this out to like thousands of iterations, you see this continue more clearly statistically, um, you see a difference in how those respond to those, those cases. If we look back to the, uh, the conversation about, um, how RF physical layers actually implement, uh, this logic, you can kind of intuitively think about how this might work. So the Atmel 86 RF either uses a longer, uh, shift register to correlate against, or has a, a much stricter threshold, uh, for, for that preamble to hit against, whereas the, the TI chips probably implement a more, uh, either a smaller shift register or a more lenient, uh, more lenient, um, um, uh, correlation, correlation threshold that it's looking at. So why, why should we care about this? Well, uh, these results allow for us to do selective receiver targeting and intrusion detection system evasion. If, uh, if say for example, we had an, like some sort of a network coordinator or an IDS or, or some sort of intelligent device in the network, um, that was doing orchestration and coordination that was built on an 86 RF chip, uh, and we were trying to attack a device that was, uh, built on a CC2420, we would be able to use a dialect that only used one or two preamble octets, uh, the, the device that we were targeting would receive it, whereas the device that was monitoring activity on the network would have no idea that that traffic even occurred. Um, so this really invalidates all of the, all the assumptions and precedent that, that a, uh, security device built on that would have been designed within. Uh, so, um, that was a finding that I have to attribute to Ryan back a couple of years ago when he initially did the research, but I think this is really profound when we think about, um, physical layers and the manner in which we trust them. So, to kind of, uh, wrap this up, I want to talk briefly about, um, RF interfaces and where we want to, where we want to take this research and what we want to enable further, further work here. So, uh, one of the challenges, um, as you just saw with presenting this demo is that developing arbitrary RF, RF content, arbitrary physical layers to inject at these receivers is not always easy to do. Um, and the reason why is because not all radios, not all COTS radios are able to generate things like arbitrary preambles or change the SFD value that it's correlating against or even change the packet format, modulation, things like that. Um, in order to do that on the physical layer, we either need to rely on software defined radio or get our hands on a transceiver chipset that enables us to configure these things. So, software defined radio, um, is, is really powerful. I just showed how 80250, GR, IEEE 80215-4 and GNU radio can be used to do this. Um, GR IEEE 80215-4 was easy to get set up with this because it's very well designed. But SDR has a ton of drawbacks too. And I say that as a huge SDR fanboy. Um, GNU radio is super, super complicated and can be pretty hard to develop for, especially if you, if, if you don't have a lot of domain knowledge or experience. Additionally, SDR hardware is pretty expensive. You know, it's a couple hundred bucks to get your hands on a basic SDR that can transmit. Um, so, you know, not everybody has one of these things just kicking around. Uh, additionally, uh, if you're doing anything that's timing sensitive. So, if you're trying to, trying to, um, fuzz sequences of packets to do anything, um, very low-level timing dependent, uh, if you're using a USB-based software to find radio and you have to go over that link between the device and the host, uh, that's a very high-latency operation. So, uh, a round-trip USB, I think is around a millisecond, um, well optimized. Um, a millisecond is, is a lifetime when we're talking about, um, uh, symbols and RF over the year. Additionally, software to find radio is pretty expensive, so it can be hard to embed. Um, when we talk about configurable transceivers that we might want to use, the issue that we run into is that transceivers are generally purpose-built and designed to do one protocol very well. Um, uh, they might be, uh, band limited in terms, in terms of where, like the frequencies at which they can tune to. So, if you're trying to experiment with, like, offsetting a channel from the, uh, the frequency that is stipulated by the standard, uh, you, you might not be able to do that. Maybe you can't specify like a floating point value to tune to. Maybe you can only give it like a channel index, for instance. Um, however, some of the, uh, the benefits you get is that they're low power, they're exposed, they're generally exposed to residual APIs that are pretty, pretty easy to work with. In some examples of these, like, these powerful but inflexible transceivers are things like, um, LTE base bands that are used in cell phones, like the two that we have on the right there, the NRF-24 chip on the left, um, and then there's an ESP for A to 211. These are good chips, but they don't really suit our purpose when it comes to fuzzing the physical layer. However, there's a certain class of hardware-defined transceivers that, uh, that have a lot of flexibility with them and can be used in a manner that's actually almost similar to software-defined radio. They have some very STR-like features built into them. Uh, and the radios that I'm going to talk about, or the first radio I'm going to talk about, um, exposes, uh, file configuration via registers in a very powerful way. Um, so we're gonna, uh, take, talk quickly about the appy mode, which is a board that Ryan designed. Um, um, and, and, and, and hobbier, as credit words do, um, that was kind of the, uh, initial, uh, the tool that enabled all this initial 802.15.4 research. And what this board did that was really unique was, um, through the good-fet framework, it exposed, uh, file configuration registers that were hidden in the CC24.20. Um, so with that, they were able to do things like modify, do just what we showed at the preamble length, but also modify the SFD value that was being looked for. Um, and it also provided a, um, a serial pin, uh, that could be pulled, uh, to basically get very, very low, uh, low-level insight, uh, real-time insight into the state of the receiver's finite state machine. So this was useful for doing, um, things like, uh, low latency injection, um, getting around some of those timing, timing limitations that, uh, that occur when you have a, uh, um, serial, um, like a USB B-link in, in line between, between the host and the, the device. However, as awesome as the app emote is, um, it's a need of an update and to use a little love. Uh, the CC24.20 is end of life, um, although we've, we have an impressive stockpile of them and we're, we're good on that for a while. Um, we are gonna have to contend with that eventually. Um, the, uh, the bill of materials for the app emote is also pretty expensive too. Um, it has, uh, like a, um, tactile switches, memory, all things designed so that you can do things like take it, throw it over a wall and leave it, come back and pick it up after you've monitored your target. But when you do research on a desktop, you don't really always need those. Yes, we'd love to make that cheaper. Additionally, in, uh, in recent years we've encountered some USB issues as, um, as, um, as, um, as, you know, Pi USB is diverged from whatever configuration is in our FTDI chip. Um, that's on the board. Um, the CC25.31 is a chip that we looked at to upgrade to. Um, however, it doesn't expose, uh, five configuration registers in the same way that the CC24.20 does. So we're limited to a much stricter implementation of a five there. So I started looking at some other chipsets, uh, things that we could build on. That led me to the which is a really interesting chip made by analog devices. It's a 2.4 gigahertz, um, uh, transceiver that supports a whole bunch of modulations including 802.15.4. Uh, it also does, you know, arbitrary FSK and I think does Bluetooth and Bluetooth Low Energy too. Um, it's a super, super powerful radio. However, the most interesting feature in my opinion is Sport Mode. So Sport Mode, um, I figured it stands for, um, some sort of an acronym. What Sport Mode essentially does is it, it uses the demodulator but bypasses the decoder and all the framing logic that's implemented in the transceiver. So what it does is it allows you to stream raw symbols over a serial interface back to a host. So if we do that and we bypass that we can then implement all those, um, those low level physical air features that we're interested in in software. Um, so that enables us to have full control of the physical air um, for, for most 2.4 gigahertz protocols. Um, super, super exciting we're really excited to build this out. Appy Mode 2.0 is going to do a lot more than 802.15.4. Um, hopefully without giving up any functionality. So with that, I'm going to briefly talk about this project I've been working on called Orthrus. That's a, it's a code name. Uh, and the reason why it's, it's called that is because it's named after a, um, a two headed dog from Greek mythology that, that, um, Hercules or Odysseus killed or something like that. Um, so it's the spiritual successor to the Appy Mode. The reason why it's named after a two headed dog is because, uh, it has two heads. It uses two, um, it uses two, um, radio front ends, uh, to do some really cool things. So it's got a, got a, um, an arm host on board for implementing, implementing radiologic on it, radio state machines. Uh, that also enables host communication to USB. Uh, but it also enables us to implement the decoding logic that we're going to be, uh, processing data from Sport Mode within to do really cool low level, low level, low level five stuff. Additionally, as I mentioned, we're going to be using two of these, um, ADF 72, 42, 42 radios on board. And the, uh, the initial reason for that is because the ADF 72 42 has a very slow retune time. So if we want to do any fast, like frequency hopping stuff or any like timing dependent, uh, things like that, uh, that's something that we might run into. Um, so for instance, Bluetooth hops, I think it's like 1600 times a second. Uh, that's really, really fast and this chip couldn't keep up with it. Um, additionally we can do things like, um, like a very fast reactive jamming where we can have one radio sitting in receive mode looking for some, like a packet to occur on the air or some state to arrive. Well, we had the other radios set, primed and ready to transmit, sitting in transmit mode so that all we have to do is send that a command and it can, it can fire very, very quickly. So this will be able to enable, um, things like high speed responsive jamming, which in the appy mode required a lot of, um, like kind of like finagling with, um, with serial lines and things like that. You guys ready to see the prototype? Check that sucker out. Um, so it's a teensy wire, teensy wire up to a dev board, um, custom hardware is in progress. Um, I would love to have some help working on this. I think it could be a lot of fun and they enable some really cool low level, um, low level physical layer stuff. Um, so if you're interested, uh, you know, come talk to me after and we can, we can, we can get you on the GitHub and stuff. Um, so, uh, kind of the initial, uh, things that we'd like to achieve is obviously implementing fight encoders and firmware so that we can start to play with them, uh, in a, in a fast iterative way. Um, additionally abstracting way, um, front end manipulation so that we can run them in a blue-green fashion, um, similar to how one might do, you know, production cloud-based software, things like that, so that we can do fast returning and channel hopping without having to, you know, do things manually. Um, something that I think is gonna be really interesting, um, beyond that though is abstracting away the radio, um, state machine so that rather than writing, um, event loops and firmware for every radio protocol we wanna implement, we can instead write a generic, um, kind of framework for doing that and then pass five configurations to it via a configuration file. So that we can write a well-designed event loop once and then implement new radio protocols just by like writing like a JSON file defining what all those values look like and things like that. I think that could be really cool. Um, so if that sounds interesting, I'd love to chat with you afterward and we can, we can make this thing awesome. So we are looking for help not just on that but on Tumble RF in general. We are going to be adding some more protocols to this and doing some more of our own research off of it. Uh, however we are sharing this and it will show you the GitHub link in a moment, uh, because we think it would be great for people to be able to add on, whether that be adding a radio interface, uh, to fuzz your favorite protocol, whether adding a generator, if you have an idea about a fuzzing state that you're like, hey, could this get a radio into a strange state? Good to add. Um, or a harness to check the device state of a device you're, uh, instrumenting against. So, uh, in addition to what Matt mentioned on the Orthris with firmware development and the state machines, we are open to collaborating with anyone who's interested in it. That is the end of our talk. Although if you really want, we can go back and show more, uh, live RF fuzzing. But, uh, but really there's the GitHub link, uh, thanks to DEF CON crew, uh, and the goons for helping us out, and to Riverloop security, cruise automation, and Ionic security for letting us do this instead of being at the office sometimes. Um, there's our contact information. You can tweet at us with complaints or compliments, um, or our email addresses. So feel free to reach out. We'd love to hear from you. We have, I think, five minutes left if anyone has questions. Um, we'll take one or two. Otherwise, after this, if you go out the doors in the back and go to your left, we will be there to answer questions so that we can keep DEF CON moving on time. Anyone have a question or two? Can, can our cheerleading crew stand up and show the audience why we're being pissed at you? Okay, okay, so the question from, the question from the front row. Yeah. Yeah. The question from the front row, uh, I believe Alex, uh, he's a little slow sometimes, asked us to go back to the beginning and start again. Um, yeah, let's do that. Thanks, Alex. Anyone else? So just one comment to wrap up. Um, as we've kind of worked through this and done more and more work on this, um, we've focused on 802.15.4. I think applying this methodology to other protocols is going to rain bugs. I think we're going to find things across all sorts of different protocols. So, um, we're excited to work on this and we'd love to get you involved if you're interested. So, I think we can wrap up. Thanks very much. Thanks very much. We'll be in the hallway on the left if you want to chat. So, thank you.