Designing RF Fuzzing Tools to Expose PHY Layer Vulnerabilities
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Knight, Matt
Speers, Ryan
In this session, we introduce an open source hardware and software framework for fuzzing arbitrary RF protocols, all the way down to the PHY. While fuzzing has long been relied on by security researchers to identify software bugs, applying fuzzing methodologies to RF and hardware systems has historically been challenging due to siloed tools and the limited capabilities of commodity RF chipsets. We created the TumbleRF fuzzing orchestration framework to address these shortfalls by defining core fuzzing logic while abstracting a hardware interface API that can be mapped for compatibility with any RF driver. Thus, supporting a new radio involves merely extending an API, rather than writing a protocol-specific fuzzer from scratch. Additionally, we introduce Orthrus, a low-cost 2.4 GHz offensive radio tool that provides PHY-layer mutability to offer Software Defined Radio-like features in a flexible and low-latency embedded form factor. By combining the two, researchers will be able to fuzz and test RF protocols with greater depth and precision than ever before. Attendees can expect to leave this talk with an understanding of how RF and hardware physical layers actually work, and how to identify security issues that lie latent in these designs.
 This talk is going to be about a software platform that we wrote to enable fuzzing RF protocols. Uh, my name is Matt Knight. I'm a senior security engineer at Cruise Automation. Um, we are hiring. If you're interested in working with us, come find me after. 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 an applied cryptography, embedded systems, special passion for IEEE 802-15-4 or Zigbee, uh, and doing automated firmware analysis. Cool. So we're gonna begin, uh, this talk in a little bit of a non-traditional way. We're actually gonna kick this off with a, uh, a demo, and then we're gonna talk about what we're watching here, um, through the rest of the talk. This'll 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 gonna be talking about. So we're gonna 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 idiosyncrasies in PhiLayer or Layer 1 implementations of fuzzing. So today we're gonna 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 gonna kick off with an overview of, uh, traditional fuzzing, kind of fuzzing is, I think most of us know it. Uh, we're also gonna comment on how those don't easily map to RF and kind of the motivations between writing the tool TumbleRF and 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 gonna 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, etc. We're feeding in unexpected input, uh, and trying to find out if we can get the system expected to stay. So overall, uh, people typically attach fuzzers to system interfaces, input, output, injecting into, like, uh, to, to feed in files, uh, to see if a file format parser works correctly, to feed in files, 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, 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 it's, it's, 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, uh, that, uh, you can use these three different pinouts to look for, um, in data rates to find digital buses on hardware, and also JTAGulator, which does the same looking for unlock JTAG. 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, it'd be non-trivial. Um, additionally are, uh, my former colleague Mark Neuland, what's up Mark? Um, when he was doing his, uh, mouse jack 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, packet injections in wireless, wireless, message 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-layer 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 expo- 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 gonna, gonna 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 gonna leave room for interpretation and there's still gonna be differences in these implement, 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 a 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 receiver's 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, 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 two, uh, layer two 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 are going to be clocked through the shift register. And the beneath it, and 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, all right, 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 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 in 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 hand it 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 at 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, different 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 PHY layers 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 TumbleRF. TumbleRF 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, this 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 in GITS. 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. Um, 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 a 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 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 file layer 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 file layer fuzzing. Um, because you can know it's because of the file layer 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 known 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 action, uh, going after, um, some certain physical characteristics in the 802.15.4 preamble. Or, sorry, 805.4 protocol. Uh, so this is what the test setup looked like. Um, 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 appy mode, which is a 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 AT86 RF230 chip on there. This is another 802.15.4 chip. And, uh, today to conduct this test I'm gonna be injecting a stimulus signal from a USRP, 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, 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 the test case generator to, uh, enumerate the preamble's. And, uh, and, and that's all that we had to do on the, the tumble RF 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, the receivers are all looking for to correlate against. And finally it'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, RF-wise 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, to configure phi characteristics, which the appy 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 GRI triple E 802-854 out of tree module, which is written by a gentleman named, a gentleman named Bastion. Um, he did a really nice job architecting it. So to cut out the phi header, all I had to do was bypass that access prefix or 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 tumble RF 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 tumble RF, using, using a radio interface. So we're going to tab 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. While you watch more thrilling live fuzzing. This was a super, super brave of us to do a live video demo of fuzzing at Tumcon. 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, alternator case, um, uh, test case here. So what this is doing is this is injecting a, um, a, uh, 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 cases, 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 going to 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, uh, 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, 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 86RF either uses a longer, uh, shift register to correlate against, or has a much stricter threshold, uh, for, for that preamble to hit against. Whereas the, the TI chips probably implements a more, uh, either a smaller shift register or a more lenient, uh, more lenient, um, um, uh, threshold, 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 86RF 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 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 for their, for their 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 chip set that enables us to configure these things. So, software defined radio, um, is, is really powerful. I just showed how 80250, GR, IEEE 802 802 504 and GNU radio can be used to do this. Um, GR IEEE 802 504 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 or do anything, um, very low level timing dependent, uh, if you're using a USB based software defined 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 defined 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, of these, like, in, 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 error. 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 SDR-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, five configuration via registers in a very powerful way. Um, so we're going to, uh, take, talk quickly about the appy mode, which is a board that Ryan designed, um, and, and Javier, it's credit where it's due, 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, five 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, serial, um, like a USB B-link in line between, between the host and the device. However, as awesome as the AppiMote is, um, it's a need of an update and can 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 materials for the AppiMote is also pretty expensive too. Um, it has, uh, 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 any 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, Pi configuration registers in the same way that the CC2420 does, so we're limited to a much stricter implementation of the Pi there. So I started looking at some other chip sets, uh, things that we could build on. That led me to the ADF7242, um, 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 error features that we're interested in, in software. Um, so that enables us to have full control over the physical error, um, for, for most 2.4 gigahertz protocols. Um, super, super exciting. We're really excited to build this out. AppiMode 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 AppiMode. 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 to do some really cool things. So it's got a, got a, um, an ARM host on board for implementing, implementing, uh, radiologic audit, 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 SportMode within to do really cool low level fi, low level fi stuff. Additionally, as I mentioned, we're going to be using two of these, um, ADF 72, uh, 72, 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 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 radio 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 API 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, teensy wired 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 faster 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 retuning and channel hopping without having to, you know, do things manually. Um, something that I think is going to 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 want to 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 TumbleRF 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 git hub 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 orthrists 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 git hub link, uh, thanks to Defcon 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 Defcon 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, the question from the front row. 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 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. Uh, thanks very much. We'll be in the hallway on the left. You want to chat? So thank you.
 This talk is going to be about a software platform that we wrote to enable fuzzing RF protocols.  Uh, my name is Matt Knight. I'm a senior security engineer at Cruise Automation.  Um, we are hiring. If you're interested in working with us, come find me after.  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 an applied cryptography,  embedded systems, special passion for IEEE 802-15-4 or Zigbee, uh, and doing automated firmware analysis.  Cool. So we're gonna begin, uh, this talk in a little bit of a non-traditional way. We're actually gonna kick this off  with a, uh, a demo, and then we're gonna talk about what we're watching here, um, through the rest of the talk.  This'll 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 gonna be talking about.  So we're gonna 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 idiosyncrasies in PhiLayer or Layer 1 implementations of fuzzing. So today we're gonna 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 gonna kick off with an overview of, uh, traditional fuzzing, kind of fuzzing is, I think most of us know it.  Uh, we're also gonna comment on how those don't easily map to RF and kind of the motivations between writing the tool  TumbleRF and 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 gonna 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, etc. We're feeding in unexpected input, uh, and trying to find out if we can get the system  expected to stay. So overall, uh, people typically attach fuzzers to system interfaces, input, output,  injecting into, like, uh, to, to feed in files, uh, to see if a file format parser works correctly, to feed in files,  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, 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 it's, it's, 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,  uh, that, uh, you can use these three different pinouts to look for, um, in data rates to find  digital buses on hardware, and also JTAGulator, which does the same looking for unlock JTAG. 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, it'd  be non-trivial. Um, additionally are, uh, my former colleague Mark Neuland, what's up Mark? Um, when  he was doing his, uh, mouse jack 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, packet injections in wireless, wireless, message 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-layer 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 expo- 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 gonna, gonna 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 gonna leave room for  interpretation and there's still gonna be differences in these implement, 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  a 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 receiver's 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,  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 two, uh, layer two 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 are going to be clocked through  the shift register. And the beneath it, and 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, all right, 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 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 in 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 hand it 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 at 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, different 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 PHY layers 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 TumbleRF. TumbleRF 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, this 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 in GITS. 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. Um, 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 a 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 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 file layer  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 file layer fuzzing. Um, because you can  know it's because of the file layer 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 known 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 action, uh, going after, um, some certain physical characteristics in  the 802.15.4 preamble. Or, sorry, 805.4 protocol. Uh, so this is what the test setup looked like. Um,  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 appy mode, which is a  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 AT86 RF230 chip on there. This is another 802.15.4 chip. And, uh, today to  conduct this test I'm gonna be injecting a stimulus signal from a USRP, 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, 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 the test case generator to, uh,  enumerate the preamble's. And, uh, and, and that's all that we had to do on the, the tumble RF  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, the receivers are all looking for to  correlate against. And finally it'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, RF-wise 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,  to configure phi characteristics, which the appy 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 GRI  triple E 802-854 out of tree module, which is written by a gentleman named, a gentleman named  Bastion. Um, he did a really nice job architecting it. So to cut out the phi header, all I had to do  was bypass that access prefix or 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 tumble RF 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 tumble RF,  using, using a radio interface. So we're going to tab 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. While you watch more  thrilling live fuzzing. This was a super, super brave of us to do a live video demo of fuzzing at  Tumcon. 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, alternator case, um,  uh, test case here. So what this is doing is this is injecting a, um, a, uh, 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 cases, 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 going to 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, uh,  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, 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 86RF either uses a longer, uh, shift register to correlate against, or  has a much stricter threshold, uh, for, for that preamble to hit against. Whereas the, the TI chips  probably implements a more, uh, either a smaller shift register or a more lenient, uh, more lenient,  um, um, uh, threshold, 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 86RF 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 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 for their, for their 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 chip set that enables us to configure these things. So,  software defined radio, um, is, is really powerful. I just showed how 80250, GR, IEEE 802  802 504 and GNU radio can be used to do this. Um, GR IEEE 802 504 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 or do anything, um, very low level  timing dependent, uh, if you're using a USB based software defined 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  defined 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, of these, like, in, 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 error. 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 SDR-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,  five configuration via registers in a very powerful way. Um, so we're going to, uh, take, talk  quickly about the appy mode, which is a board that Ryan designed, um, and, and Javier, it's  credit where it's due, 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, five 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, serial, um, like a USB B-link in line between, between the host and the device. However,  as awesome as the AppiMote is, um, it's a need of an update and can 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 materials for the AppiMote is also pretty expensive too. Um, it has, uh, 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 any 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, Pi configuration registers in the same way that the CC2420 does, so we're  limited to a much stricter implementation of the Pi there. So I started looking at some other  chip sets, uh, things that we could build on. That led me to the ADF7242, um, 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 error features that we're interested in, in software. Um, so that enables us to have full  control over the physical error, um, for, for most 2.4 gigahertz protocols. Um, super, super  exciting. We're really excited to build this out. AppiMode 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 AppiMode. 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 to do some really cool  things. So it's got a, got a, um, an ARM host on board for implementing, implementing, uh,  radiologic audit, 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  SportMode within to do really cool low level fi, low level fi stuff. Additionally, as I  mentioned, we're going to be using two of these, um, ADF 72, uh, 72, 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 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 radio 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 API 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,  teensy wired 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 faster 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 retuning and channel hopping without having to, you know, do things manually. Um, something  that I think is going to 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 want to 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 TumbleRF 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 git hub 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 orthrists 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 git hub link, uh, thanks to  Defcon 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 Defcon 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, the question from the front row. 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 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. Uh, thanks very much.  We'll be in the hallway on the left. You want to chat? So thank you.
DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_0_911.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_912_1223.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_1224_1427.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_1428_1727.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_1728_1799.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_1800_1943.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_1944_2051.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_2052_3779.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_3780_3995.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_3996_10595.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_10596_10955.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_10956_11555.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_11556_12263.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_12264_13511.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_13512_18803.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_18804_19763.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_19764_19919.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_19920_21803.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_21804_21899.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_21900_22823.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_22824_22919.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_22920_23423.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_23424_27047.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_27048_28595.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_28596_30023.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_30024_31979.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_31980_33227.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_33228_34919.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_34920_35195.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_35196_35435.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_35436_35615.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_35616_35903.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_35904_36275.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_36276_36455.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_36456_37379.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_37380_40175.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_40176_41531.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_41532_41627.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_41628_41699.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_41700_45359.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_45360_48935.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_48936_50591.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_50592_50735.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_50736_53087.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_53088_56159.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_56160_56327.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_56328_56459.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_56460_57131.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_57132_57395.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_57396_57527.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_57528_57803.png DEF_CON_26_-_Knight_and_Speers_-_Designing_and_Applying_Extensible_RF_Fuzzing_Tools_9K1_ISLS5UE_57804_58736.png