Designing RF Fuzzing Tools to Expose PHY Layer Vulnerabilities

Video thumbnail (Frame 0) Video thumbnail (Frame 1426) Video thumbnail (Frame 2225) Video thumbnail (Frame 3495) Video thumbnail (Frame 4279) Video thumbnail (Frame 5621) Video thumbnail (Frame 7588) Video thumbnail (Frame 10992) Video thumbnail (Frame 12256) Video thumbnail (Frame 13510) Video thumbnail (Frame 15083) Video thumbnail (Frame 16899) Video thumbnail (Frame 18799) Video thumbnail (Frame 19693) Video thumbnail (Frame 21795) Video thumbnail (Frame 23825) Video thumbnail (Frame 27039) Video thumbnail (Frame 28593) Video thumbnail (Frame 29384) Video thumbnail (Frame 31284) Video thumbnail (Frame 33287) Video thumbnail (Frame 34916) Video thumbnail (Frame 35787) Video thumbnail (Frame 36666) Video thumbnail (Frame 39594) Video thumbnail (Frame 41134) Video thumbnail (Frame 44083) Video thumbnail (Frame 45351) Video thumbnail (Frame 47294) Video thumbnail (Frame 48925) Video thumbnail (Frame 50558) Video thumbnail (Frame 53077) Video thumbnail (Frame 56038)
Video in TIB AV-Portal: Designing RF Fuzzing Tools to Expose PHY Layer Vulnerabilities

Formal Metadata

Title
Designing RF Fuzzing Tools to Expose PHY Layer Vulnerabilities
Alternative Title
Designing and Applying Extensible RF Fuzzing Tools
Title of Series
Author
License
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.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
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.
Focus (optics) Chemical equation Cellular automaton Mathematical analysis Software-defined radio Bit Software-defined radio Cryptography Information technology consulting Loop (music) Computer science Communications protocol Information security Firmware Loop (music) Computing platform Physical system
Operations research Computer font State of matter Software-defined radio Bit rate Grand Unified Theory Control flow Statistics Thread (computing) Shareware Graphical user interface Network socket Interface (computing) Codec Fuzzy logic Video game Software testing Computer music Information Process (computing) output
Dialect Implementation Dialect Physicalism Computer network Software bug Finite element method Intrusion detection system Synchronization Different (Kate Ryan album) Intrusion detection system Software Videoconferencing Finite-state machine Fuzzy logic Finite-state machine Ideal (ethics) Information security Local ring Loop (music) Fingerprint Wireless LAN Physical system Fingerprint
State of matter File format Virtual machine Online help Software bug Crash (computing) Pseudozufallszahlen Semiconductor memory Software Personal digital assistant Shared memory Computer hardware Automation Fuzzy logic output Loop (music) Physical system Parsing Tesselation File format Interface (computing) Computer file State of matter Computer network Parsing Software Personal digital assistant Crash (computing) Interface (computing) output Ideal (ethics) Information security Communications protocol Physical system
Standard deviation State of matter Hooking Bit rate Semiconductor memory Different (Kate Ryan album) Software Computer hardware Uniqueness quantification Energy level Fuzzy logic Firmware Loop (music) Personal identification number Interface (computing) Digitizing State of matter Digital signal Instance (computer science) Cartesian coordinate system Software Interface (computing) Fuzzy logic Information security Communications protocol Firmware
Group action Supremum Computer file State of matter Characteristic polynomial Shape (magazine) Mereology Commercial Orbital Transportation Services Power (physics) Latent heat Crash (computing) Different (Kate Ryan album) Software framework Communications protocol Extension (kinesiology) Software protection dongle Loop (music) Injektivität Standard deviation Projective plane Keyboard shortcut Shared memory Commercial Orbital Transportation Services Limit (category theory) Latent heat Function (mathematics) Fuzzy logic Finite-state machine Quicksort Information security Wireless LAN Communications protocol Fingerprint Software protection dongle
Metre Web page Standard deviation Implementation Different (Kate Ryan album) Computer-generated imagery Interpreter (computing) Physics Loop (music) Fingerprint
Differential (mechanical device) Shared memory 1 (number) Sampling (statistics) Analogy Digital signal Food energy Inverse element Distance Mereology Spektrum <Mathematik> Frequency Personal digital assistant Different (Kate Ryan album) Telecommunication Synchronization Physics OSI model Energy level Information security Communications protocol Fingerprint Loop (music)
Information Waveform Multiplication sign Digital signal Line (geometry) Cartesian coordinate system Sequence Power (physics) Wave packet Number Element (mathematics) Word Frequency Synchronization Synchronization Software framework Representation (politics) Pattern language Software framework Information security Boiling point Loop (music)
Ocean current Email Implementation State of matter Confidence interval Shift register 1 (number) Parsing Bit rate Distance Cyclic redundancy check Thresholding (image processing) Number Exclusive or Cross-correlation Bit rate Different (Kate Ryan album) Operator (mathematics) String (computer science) Pattern language Software framework Loop (music) International Date Line Module (mathematics) Matching (graph theory) Length State of matter Physicalism Bit Hamming distance Shift register Thresholding (image processing) Sequence Symbol table Parsing Distance Symbol table Exclusive or Cross-correlation Pattern language Finite-state machine Information security Table (information) Communications protocol Abstraction Resultant Row (database)
Word Word Process (computing) Different (Kate Ryan album) Synchronization State of matter Synchronization Ideal (ethics) Ideal (ethics) Information security Loop (music)
Electric generator Addition Computer file Projective plane Client (computing) Different (Kate Ryan album) Personal digital assistant Personal digital assistant Interface (computing) Fuzzy logic Software testing Ideal (ethics) Quicksort Communications protocol Information security Communications protocol Loop (music)
Greatest element User interface State of matter Line (geometry) Multiplication sign Mach's principle Architecture Software Personal digital assistant Software framework Software testing Diagram Communications protocol Digital rights management Loop (music) Computer architecture Electric generator Shareware Data management Personal digital assistant Interface (computing) Software framework Software testing Right angle Pattern language Quicksort Information security Communications protocol Resultant Row (database) Extension (kinesiology)
Standard deviation Injektivität Length State of matter Set (mathematics) Bit rate Function (mathematics) Software framework Process (computing) Extension (kinesiology) Physical system Social class Electric generator Mapping Latent heat Message passing Process (computing) Interface (computing) Software framework output Software testing Quicksort Video game console Information security Electric generator Random number Functional (mathematics) Game controller Open source Computer file Goodness of fit Software Software testing output Message passing Macro (computer science) Loop (music) Serial port Standard deviation Interface (computing) Cartesian coordinate system Template (C++) Symbol table Symbol table Radius Personal digital assistant Function (mathematics) Fuzzy logic Communications protocol Computer worm Extension (kinesiology)
Laptop Default (computer science) Group action Interface (computing) Characteristic polynomial Physicalism Control flow Shareware Exterior algebra Personal digital assistant Crash (computing) Personal digital assistant Interface (computing) Videoconferencing Software framework Software testing Series (mathematics) Whiteboard Implementation Information security Communications protocol Loop (music) Row (database) Extension (kinesiology)
Laptop Line (geometry) Interface (computing) Software-defined radio Shareware Mach's principle Revision control Architecture Personal digital assistant Personal digital assistant Interface (computing) Logic Software testing Software testing Software framework Whiteboard Information security Pairwise comparison Digital rights management Loop (music) Asynchronous Transfer Mode Computer architecture
Standard deviation Email Length Interior (topology) Characteristic polynomial Software-defined radio Element (mathematics) Number Computer hardware Software framework Loop (music) Module (mathematics) Standard deviation Email Block (periodic table) Length Bit Hexagon Process (computing) Software Mixed reality Network topology Configuration space Quicksort Information security Asynchronous Transfer Mode
Beat (acoustics) Computer font Moment (mathematics) State of matter Water vapor Grand Unified Theory Control flow Shareware Thread (computing) Shareware Network socket Personal digital assistant Videoconferencing Source code Fuzzy logic Software testing Computer music Process (computing) Information output ASCII Resultant
Beat (acoustics) Computer font Game controller State of matter Multiplication sign Web page Control flow Thread (computing) Oscillation Geometry Graphical user interface Exterior algebra Personal digital assistant Network socket Software testing Computer music Software testing Software framework Iteration Information Process (computing) output Position operator
Slide rule Multiplication sign Function (mathematics) Graph coloring Oscillation Different (Kate Ryan album) Personal digital assistant Videoconferencing Source code Software testing Data conversion Communications protocol Loop (music) Scripting language Dependent and independent variables Validity (statistics) Content (media) Computer Shareware Personal digital assistant Logic Right angle Iteration Information security Communications protocol Resultant
Dialect Software Shift register Intrusion detection system Coordinate system Quicksort Information security Thresholding (image processing) Information security Loop (music) Resultant
Digital signal processor Electric generator Link (knot theory) File format Interface (computing) File format Content (media) Physicalism Software-defined radio Public domain Software-defined radio Commercial Orbital Transportation Services Power (physics) Shareware Operator (mathematics) String (computer science) Software Order (biology) Computer hardware Interface (computing) Information security Loop (music)
Point (geometry) Email Suite (music) Software-defined radio Power (physics) Frequency Bit rate Term (mathematics) String (computer science) Computer hardware Musical ensemble Configuration space Communications protocol Loop (music) Social class Standard deviation Software-defined radio Instance (computer science) Group action Symbol table Subject indexing Configuration space Musical ensemble Information security Communications protocol
Mobile app Implementation Injektivität State of matter Length Multiplication sign Materialization (paranormal) Real-time operating system Goodness of fit Semiconductor memory Finite-state machine Software framework Configuration space Loop (music) Personal identification number Injektivität Digital signal Line (geometry) Limit (category theory) Word Configuration space Finite-state machine Whiteboard Information security Asynchronous Transfer Mode
Email Asynchronous Transfer Mode Game controller Functional (mathematics) Proxy server Streaming media Mach's principle Analogy Software Software framework Communications protocol Implementation Loop (music) Module (mathematics) Serial port Inheritance (object-oriented programming) Serial communication Physicalism Ext functor Streaming media Mereology Control flow Symbol table Computer configuration Logic Quicksort Information security Communications protocol Asynchronous Transfer Mode
Serial port State of matter Multiplication sign Disk read-and-write head Arm Front and back ends Frequency Prototype Coefficient of determination Very-high-bit-rate digital subscriber line Telecommunication Energy level Implementation Loop (music) Dependent and independent variables Arm Projective plane Instance (computer science) Control flow Virtual machine Curvature Telecommunication Finite-state machine Information security Asynchronous Transfer Mode
Implementation Link (knot theory) Computer file State of matter Online help Event horizon Product (business) Programmschleife Whiteboard Finite-state machine Energy level Software framework Configuration space Codierung <Programmierung> Implementation Fuzzy logic Communications protocol Abstraction Firmware Loop (music) Tunis Addition Dataflow Software developer Moment (mathematics) Code Physicalism Generic programming Cloud computing Front and back ends Loop (music) Event horizon Software Green's function Interface (computing) Configuration space Software testing Finite-state machine Whiteboard Information security Arithmetic progression Communications protocol Routing Firmware
Email Information Link (knot theory) Multiplication sign Chemical equation Computer-integrated manufacturing Software bug Loop (music) Different (Kate Ryan album) Office suite Quicksort Information security Information security Communications protocol Loop (music) Address space Row (database)
this talk is going to be about a software platform that we wrote to enable fuzzing RF protocols my name is
Matt Knight I'm a senior security engineer at cruise
automation we are hiring if you're interested in working with us come find me after I also leave the RF practice at River loop security which is a embedded embedded security consultancy if you go back far enough I got a bachelor's in electrical engineering from Dartmouth and pretty much everything have done since then it's been all about like embedded systems and software-defined radio it's me and hi I'm Ryan Spears I'm the co-founder at River loop security that as matt said does embedded a phoner ability in RF consulting I also lead research at ionic security I guess I'll claim we are also all hiring my backgrounds in computer science but my focus after that's been in applied cryptography embedded systems special passion for I Triple E 802 15 4 or ZigBee and doing automated firmware analysis cool so we're gonna begin this talk a little bit of a non-traditional
way we're actually gonna kick this off with a demo and they're going to talk about we're watching here to rest of the
talk this will just take about 15
minutes so when when Ryan and I were were conceptualizing this research we were thinking what could be the most boring demo to possibly show on stage at
Def Con and we thought that life really can't get much worse than live fuzzing so that's what we're gonna be talking about
so we're gonna come back to that the the background for this talk and I wanted to do that for like another five minutes but he said no so the the background a few things that you might be interested in the some of the research here builds on research we did in making and breaking a wireless intrusion detection system which myself and Xavier presented at troopers as well as an ACM paper about speaking the local dialect which was about idiosyncrasy video sync receives in fie layer or layer 1 implementations of fuzzing so today we're going to talk about how we can use these for not just use the fuzzing to do bug discovery but also to figure out differences about the physical layer finite state machine and then generating fingerprints to identify chips differently based on that cool so we're
gonna kick off with an overview about traditional fuzzing kind of fuzzing is I
think most of us know it we're also going to comment on how those don't easily map to RF and kind of the
motivations between writing the tool humble or talked about later on we'll
talk about some of the design principles that went into it and then finally we'll we'll come back to that example we
showed kind of show the significance of it and we're going to wrap up ruminations on hardware and where we want to go with this research to enable fuzzing arbitrary wireless protocols sure so going through and I think most
people know or have some background in this so we'll go through relatively quickly 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 in trying to find out if we can get the system you expect over all people typically attach fuzzers to system interfaces input/output injecting into like tiles to see if a file format parser works correctly to feed bad or malformed data into network interfaces or to play around with the memory state of a machine and for software there's a lot of really great tools out there right AFL which is a pretty advanced tool that uses memory introspection to help advance it's it's a state coverage peach fuzzer which although is a legacy
tool is still still used today and SCAP II which is a network protocol generator but also has some basic fuzzing in it now what's interesting with software is you can instrument and hook it many levels you can control typically when it starts execution when it finishes monitor the state monitor State through
hooks or memory execution but what else can one fuss cool so briefly gonna run through some other applications of fuzzing so fuzzing hardware is something that's been done in a couple different through a couple different approaches the challenge is that hardware with hardware the interface is off a lot less trivial to monitor than it is in software where you control execution where you have easy ability to kind of attach that interface so it may not be easy to get a harness that can hook into hardware and monitor its state but there are some some pretty interesting approaches that have been made here for instance AFL unicorn which emulates firmware to and outs to look for data rates to find digital buses on hardware and also jtagulator which does the same looking for unlock JTAG so those are kind of like fuzzing unlike hardware interfaces to try to find pin outs and things like that and there's some others too we
talked about fuzzing RF there are a couple different projects I want to comment on just to kind of frame the state-of-the-art why fuzz is an open-source project that's a layer two focused 802 11 buzzer again it's just focused on on the Mac layer and it doesn't engage the Phi really at all it's also built pretty
specifically for 802 11 so to take that and move it over to or extend it to
support another wireless protocol would be non-trivial additionally our my
former colleague Mark Newland sup mark when he was doing his mouse jack research two years ago he used fuzzing as part of his methodology for um for injecting packets at these n RF 24 hid dongles to find different packet injections and wires wireless mice and keyboard protocols mark chose not to open-source his tools for that shame on you mark same-same so we cannot we cannot build on his great work and additionally if we go back to Ryan's original 802 15 4 file layer fuzzing research he wrote the isotope framework which was a 802 15 4 fuzzer again that was also a fairly protocol specific and not easy to extend same shape so kind of tied that up limitations of existing RF fuzzers is that they are generally siloed in protocol specific they might use a cots radio chipset that may or may not expose the fly and they're there and they're generally limited to like a single protocol because they're built with certain features in mind additionally as with Hardware RF state is pretty challenging the instrument you know it's really hard to measure what constitutes a crash or some sort of a weird behavior in in in a an RF protocol whether it's you know it like a traditional at layer 2 approach or if you're trying to identify behavior on the Phi additionally you know if we're using a cots radio chipset we're kind of forced to trust what it's giving us we don't have a lot of visibility into the execution what's actually happening on the fight chip so that's part of what we're trying to exploit exposed with this research because there's an interesting characteristic here and that's the not all five state machines are created equally and I'm just gonna kind of 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 they want a standard say your power company decides that 802 15 4
isn't sufficient for doing wireless meter reading any anymore and they want something new they all get together in a room with a whole bunch of stakeholders they spend years talking about it they decide what they want to be in the standard and then they turn that into a nice easy to read 5,000 page document that may or may not be freely available you may have to buy it they might make
it available but anyway different manufacturers get this standard they take it home and then they have to
interpret it and turn those interpretations into into a chip you have to take that and turn that into something actually works and as you might imagine even the most well-formed closed comprehensively defined standard is still going to leave room for interpretation and there's still gonna be differences in these implement implementations that we can that we can monitor and begin to instrument off of some of these differences could be pretty profound and can be exploited as the initial ADA 211 research showed so
we're gonna show how these fuzzing methodologies can be applied to RFI's to expose different corner cases in these protocols before we do that
we're just gonna share a brief primer on how radio frequency communications actually work and this would be very
very high-level so we're talking about radios here and radios or devices that take ones and zeros and translate them into electromagnetic energy for the purpose of transmitting them over some distance and air gap distance and they do the inverse - so we're talking about transmitting we're going from ones and zeros into electromagnetic energy we're talking about receiving we're taking electromagnetic energy and going back into ones and zeros and the hardest part was building a receiver has to do with samp sampling and synchronizing on the the energy state that that represents a signal so I have just a picture were to
talk about briefly does anybody in the audience know what this is I heard baud lines so that's the name of the tool but this is a representation of a spectrogram so what we have here is we have time in the x-axis frequency on the y-axis and then power in the z-axis so we're looking to signal here and
we're just gonna talk briefly about what's here we've got a periodic pattern that repeats in the beginning it's a preamble and that's just an alternating 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 there's an element called a start of frame delimiter and what that is is that's a discontinuity from the preamble that is a magic number so the receivers know to look for the start of frame delimiter and when it sees it it's gonna say okay I'm done receiving the preamble I'm gonna lock on to this and just start reading out bits and that represents the rest of the rest of the data so the preamble is kind of the training sequence the start of frame delimiter marks the end of it and then the data follows so we can boil a rough
abstraction of an RF state machine down to look something like this where when the radio chipset is in its idle State it's looping over the seeking preamble state when it sees that it's receiving a preamble it moves on to the seeking sfd state if it receives an SF D it basically starts reading up data for some some some number of bits before presenting that up to the layer 2 layer 2 parser in some way so we're gonna dig into these two states and talk about to kind of frame physical layer fuzzing so the way these two states work is they essentially run a correlation operation across the symbols that are being received from the from VG modulator so this correlation is basically a shift register that's clocking demodulated bits through at the symbol rate well it's looking for a pattern so when we're looking for the preamble we're looking for that alternating sequence of zeros and ones that 0 1 0 1 0 1 and when we get a good-enough match then we can say with confidence we've received the preamble we're about to receive a packet let's go to the next state and start looking for the s FD and that's a very similar operation although instead of looking for that 0 1 0 1 we're looking for whatever the magic number of that protocol is so just to kind of
illustrate this briefly talk about this this table here so on top we have our F symbol values that would be clocked through the shift register and the beneath it and the preamble correlation value Row is the magic number that our physical layer scan looking for here a pretty standard implementation here is just to have that alternating 0 1 0 1 pattern so what this correlator is going to do is it's going to XOR the current state 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 handing distance to be 0 or very very close to 0 so if say we had an arbitrary packet on the air and we're clocking these values through 0 1 0 1 0 1 you can see the handing distance changes it goes up and down until finally we've loaded the preamble into the shift register we can say with confidence all right these two strings match or match below a certain threshold we think we're receiving a packet we're gonna move into the next state 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 0 1 0 1 we're looking for that magic number well
it turns out as Ryan's research a couple years ago discovered not all of these syncwords and preambles are implemented they're not all implemented the same way across manufacturers so certain chip states were found to correlate on different preambles and syncwords than others so that's really interesting because as attackers if we're able to strategically malformed or leverage that we can get radios to do really interesting things so we can do things like send short preambles send different sync words and characterize how these different chipsets perform and we can automate the discovery of this process
by applying fuzzing so with that I'm gonna hand it back over to Ryan and he's going to talk through the design of an ideal RF buzzer 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 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 etc then we wanted to be have flexibility and how we generated the test cases there's a lot of great tools some of which we talked about earlier that can generate fuzzing test cases some regenerative some are mutated if we wanted to be able to plug those different ones in in a flexible way and then reusable and I think this was a main one for us we had done this research on 802 15 4 we want to do some of this and poured it over to other protocols we'll talk some more about that at the end and then lastly the comprehensive alludes to the fact that we didn't want to just fuzz layer 2 and above the Mac layer and forward we also wanted to expose the file ayres so that we could tweak it and fuzz that and that's something that is sort of unusual in a lot of fuzzers so out of that came
something that we are releasing and talking about called tumble RF tumble RF
is a software framework for fuzzing arbitrary RF protocols and there's sort of three things that it abstract out first of all the radio API second how do we do the test case generation and lastly how do we what we call the harness which I'll talk about more in a minute it's 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 the sort of the middle 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 are then what we want to do is be able to change out the stuff on the top the right or the bottom the test case generator which creates sort of the byte patterns that we're going to send out on the radio the harness which measures the state of the target and as the lightning bolt which we all know is how RF looks is how we transmit right from the bottom thing and so we send lightning bolts across from the transmitter to the receiver they wanted to 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 shoot your PA out but yeah we we have made lightning bolt at times not on purpose so I'm gonna step through
each of the interfaces and the reason that I'm sort of gonna go into the depth more than we may typically do is because we want you to understand that this is a simple we hope easy we hope usable we hope interface that you can take modify and extent so if you want to add a new radio what you need to do is implement the interface and to do this you basically inherit this class it's Python and implement a few functions transmit start receiving stop receiving you know get radio frames and then we have a few set and gets and this is to change the channel but also some of the stuff if you have the ability on the interface you're working with to set the sfd or the preamble and that gets into some of the file a or fuzzing that we'll be using today 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 the goal of this is to integrate between either something that you're writing custom for a protocol or maybe you're tying into one of the fuzzers like peat source copy 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 stand you know as the standard specifies and then the other is something that yields test cases and this spits out the per muted input the randomized import or wherever we're going to use to try to cause a bad state in what we're showing today we're going to be using the preamble length generator but we also implemented two others we'll show you the preamble length in a minute more Illustrated the other one is to put name non-standard symbols in so if the standard says this map pointed out earlier 0 1 0 0 1 0 1 0 1 what if we start changing that 1 1 0 0 1 1 0 0 I'm seeing what happens to the radius there we also can put random payloads in the message as an example that this is not just applicable to file a or fuzzing like we're focusing on today but also fuzzing the macro application layers in the last major of the classes that you can implement is
the harness the harnesses job is to evaluate the device under test see if it's in a good state bad state or because this is important in embedded fuzzing too reset it get it back into a good state when we caused it to go haywire and so we have different ways to do this today for simplicity we will 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 fie layer fuzzing because you can know it's because of the five layer and not because of some upper layer because we can configure other things out of there but also if you're working against a real target you are often won't be able to do that you may monitor it state by seeing if you get it in the acknowledgement frame back if it acts your 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 then you can see if you're getting good output that 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 of their 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 and the purpose for that is to just alternate between no and good States to see if we're still operational after injecting cool so I'm going to
show you a quick demo of tumble RF in action going after a certain physical air characteristics in the AO to 15-4 preamble 800 15 for protocol so this is what the test setup looked like we're gonna show recorded video demo at def cons request so here's here's a laptop that's running the tumble RF framework just running it natively and hooked up to it are a series of dead boards so we
have three devices under test that we looked at they're all 802 15 for boards from left to right we have this T ICC 24 20 which is mounted on an apnea mode which is a 802 15 for test board that Ryan designed a couple years ago next to that we have a dev board from TI that contains a TI cc 25 31 which is essentially the updated version of the CC 24 20 and then right next to it plugged into the laptop that small black dev board is an atmel RZ USB stick which has the 8086 RF 230 chip on there is another 802 15 for chip and today to conduct this test I'm going to be injecting a stimulus signal from a USR be us our PB 210 which is just a software-defined radio any software-defined radio would work with this methodology so when we talk about
our architecture here the three dev boards on top are going to be tied into the framework via an Rx interface within the harness and then the TX interface injecting into the injecting into the end of these devices is going to be us RP suffered fine radio all we had to do was extend the test case generator to enumerate the the preambles and and that's all that we had to do on the tumble RF side to get this ready to go so the case we're going to be looking at
here is the 802 15 for preamble so the standard the inter to 15 15 for standard stipulates the the Phi header is comprised of three elements the first is for octet of hex 0 valued bytes so we have for octet sub 0 that represents the preamble finally or after that start of frame delimiter is hex a 7 in the standard that's the magic number the magic number the the receivers are all looking for to correlate against and finally that's followed by one octet of length it's actually only seven bits but but there's one gonna use bit in there but that follows that that's in the standard so we're going to do is we're gonna experiment with the preamble length so we're gonna see what happens as we begin to take away preamble octet as we we send stimulus frames at these receivers to see what what we can reveal so to generate this data I'm actually
using denier radio since this is a software-defined radio it's basically a blank canvas for us to do anything that we want RF wise with it we could use a hardware to find radio if we had access to low-level registers that allowed us to configure the to configure fie characteristics which the abbey mode does but for simplicity and for kind of mutability software-defined radios a nice way to do this so I'm using the GRI Tripoli 802 802 15 for outer tree module which is written by a gentleman gentleman named Bastian he had a really nice job architecting it so to cut out the fie header all I had to do is bypass that access prefix herb lock so with that what that block normally does is it depends the the preamble sort of frame delimiter in the length when you bypass that it doesn't do that which means that I can then go upstream into tumble RF and implement those values in software on the host so it becomes super super easy to iterate over 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 tap over and show
quick demo here we'll pick up where we left off give us
a moment to take a second water well you
watch more thrilling live fuzzing this
was a super super brave of us to do a
live video demo of fuzzing a con so thank you for thank you 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 test case generator or
sorry the alternative the alternator
case test case here so what this is doing is this is injecting a a control case a standard 802 15 for frame to make
sure that the radios in a known good state before injecting a test case and
the reason why we always send a control case before test case is if we want to
run this thing and go to lunch and run
it like ten thousand times if it crashes on the three hundred iteration we don't want to have you know nine thousand false positives following it we want to make sure that the radio is a known testable good state before we before we
send data into it so at the end at the end of it we can jump over use the port press results script that we have to print it out pretty printed and then we can talk about it in the next slide so we're gonna go back to the slides but it'll have the same content if you remember test case six and eight have interesting switch from valid verse invalid verse so if we look at this doing drug you want me to computer for you yes please
okay cool so now what the output of that is is in the upper right hand corner it's actually from a different run but it's about the same results we've just ran over 50 iterations when we're actually doing this we run much longer 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 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 but you have three behaviors coming out of that right and so if we look for example between the CC 2420 in the upper left the one on the a PMO and the Atmel 86 RF that we just showed you the video filling video demo of one thing that you'll notice for example is that test case 2 & 4 or received most of the time on the CC 2420 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 2 in the amount and when we break this out to like thousands of iterations you see this continued more clearly statistically you see a difference in how those respond to those those cases so if we look back to the conversation about how our physical layers actually implement this logic you can kind of intuitively think about how this might work so the Atmel 86 RF either uses a longer
shift register to correlate against or has a much much stricter threshold for for that preamble to hit against whereas the the TI chips probably implements a more other a smaller shift register or more leaning more lenient threshold and threshold of just looking at so why should we care about this well these
results allow for us to do selective receiver targeting and intrusion detection system evasion if if say for example we had in a like some sort of a network coordinator or an IDs or some sort of intelligent device in the network that was doing orchestration and coordination that was built on an 86 RF chip and we were trying to attack a device that was built on a CC 2420 we would be able to use a dialect that only used one or two preamble octets the device that we're targeting would receive it whereas the device that was monitoring activity on the network would have no idea that that traffic even occurred so this really invalidates all of the all the assumptions and precedent that that a security device built on that would have been designed with them so that was a
finding that I have to tribute to Ryan back a couple years ago neap initially did the research but I think this is really profound and we think about physical layers in the manner in which we trust them so to kind of wrap this up I want to talk briefly about RF interfaces and where we want to where we want to take this research and we want to enable further further work here so
one of the challenges as you just saw
with presenting this demo is that developing arbitrary RF RF content arbitrary physical layers to inject these receivers is not always easy to do 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 is correlating against or even change the packet format modulation things like that in order to do that on the physical layer we either need to rely on software-defined radio or get our hands on a transceiver chipset that enables us to configure these things so software-defined radio is really powerful I just showed how 802 50gr I Triple E 802 15 for candy radio can be used to do this gr I Triple E 802 15 4 was easy to get set up with us because it's very well designed but str has a ton of drawbacks too and i say that is a huge SDR fanboy the new 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 it's a couple hundred bucks to get your hands on a basic str that can transmit so you know not everybody has one of these things just kicking around additionally if you're doing anything that's timing sensitive so if you're trying to try to win stirs of packets to do anything very low-level timing-dependent if you're using a USB based software-defined radio and you have to go over that link between the device and the host that's a very high latency operation so a roundtrip USB I think is around a millisecond well optimized a millisecond is a lifetime when we're talking about symbols and RF over the air additionally suffer to find radios pretty expensive so it can be hard to embed 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 they might be a band limited and turns 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 the frequency that is stipulated by the standard 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 however some of the the benefits you get is that their low-power they're supposed they're generally exposed over serial api's that are pretty pretty easy to work with and some examples of these like in these powerful but inflexible transceivers or things like LTE baseband that are used in cell phones like the two that we have on the right they're the NRF 24 chip on the left and then there's an ESP for 802 11 these are good chips but they don't really suit our purpose when it comes to fuzzing the physical air however there's
a certain class of hardware to find transceivers that that have a lot of flexibility with them and can be used in a manner that's actually almost similar to software-defined radio they have some very STR like features built into them and the radios that I'm going to talk about or the first rate I'm going to talk about exposes fly configuration via registers in a very powerful way so we're gonna take talk quickly about the
a p mode which is a board that ryan designed mafia and in Javier asked red words - that was kind of the initial the tool that enabled all this initial 802 15 for research and what this board did that was really unique was through the good FET framework it exposed fie configuration registers that were hidden and the CC 2420 so with that they were able to do things like modify do just what we shared if the preamble length but also modify the SFG value that was being looked for and it also provided a serial pin that could be pulled to basically get very very low low-level insight real time insight into the state of the receivers finite state machine so this was useful for doing things like low latency injection getting around some of those timing timing limitations that that occur when you have a cereal like a USB B Lincoln line between between the host and the device however
as awesome as the app emote is it's a need of an updating to use a little of the CC 2420 is end-of-life although we've we have an impressive stockpile of them and we're good on that for a while we are gonna have to contend with that eventually the the bill materials for the app mode is also pretty expensive too it has like a tactile switches memory all things designed so that you can do things like take it photo it over a wall and leave it come back and pick it up after you've monitored your target but when you're doing research on a desktop you don't really always need those yes we'd love to make that cheaper additionally in in recent years we've encountered some USB issues as as as as you know pi USB has diverged from whatever configuration is in our FTDI chip that's on the board the CC 25 31 is a chip that we looked at to upgrade to however it doesn't expose fight configuration registers in the same way that the CC 24 20 does so we're limited to a much restrictor implementation of the Phi there so I started looking at some other chipsets as things that we could build on that led me to the atf
72-42 which is a really interesting chip made by analog devices it's a 2.4 gigahertz transceiver that supports a whole bunch of modulations including 802 15 4 it also does you know arbitrary FSK and I think those Bluetooth in Bluetooth low-energy to is a super super powerful radio however the most interesting feature in my opinion is sport mode so sport mode I figured it
stands for some sort of an acronym what a 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 draw symbols over a serial interface back to a host so if we do that we bypass that we can then implement all those those low-level physical layer features that were interested in in software so that enables a snap full control over the physical layer from for most 2.4 gigahertz protocols super super exciting we're really excited to build this out happy mode to point O is going to do a lot more than a tooth team four hopefully without giving up any functionality so with that I'm gonna
briefly talk about this project I've been working on called orthrus that's it's a codename and the reason why it's it's called that is because it's named
after a a two-headed dog from Greek mythology that that Hercules or Odysseus killed or something like that so it's the spiritual successor to the IP mode the reason why it's named after two-headed dog is because it has two heads it uses two it uses two radio front-ends to do some really cool things so it's got a got a an armed host on board for implementing radiologic on it radio state machines that also enables host communication to USB but it also enables us to implement the decoding logic that we're going to be processing data from sport mode within to do really cool little flat level low level 5 stuff additionally as I mentioned were going to be using two of these 80 f72 472 442 radios on board and the initial reason for that is because the EDF 72-42 has a very slow retune time so if we want to do any fast the frequency hopping stuff or any timing dependent things like that that's something we might run into so for instance Bluetooth hops I think it's like sixteen hundred times a second that's really really fast and this ship couldn't keep up with it additionally we can do things like a very fast reactive jamming where we can have one radio sitting in receive mode looking for some like a packet to occur on the air or some state to arrive well we have 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 making it can fire very very quickly so this will be able to enable things like high speed responsive jamming which in the a P mode required a lot of like kind of like finagling with with serial lines and things like that you guys ready to see the prototype
check that sucker out so it's a TTY teensy wired up to deaf board custom hard was in progress 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 the level physical air stuff so if you're interested you know come talk to me after we can we can we can get you on the github and stuff so kind of the initial things that we'd like to achieve is obviously implementing Phi decoders and firmware so we can start to play with them in a fast iterative way additionally abstracting away front-end manipulation so that we can run them in a Bluegreen fashion similar to how one might do you know production cloud-based software things like that so that we can do faster route tuning and channel hopping without having to you know do things manually something that I think is gonna be really interesting beyond that though is abstracting away the Radio state machine so that rather than writing event loops and firmware for every radio protocol we want to implement we can instead write a generic kind of framework for doing that and then pass fly configurations to it via a configuration file so that we can write a well-designed vent 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 so if that sounds interesting I'd love to chat with you afterward and we can we can make this thing awesome so we are looking for help not just on that but on tumble RF in general we are going to be adding some more protocols to this and doing some more of our own research off of it however we are sharing this and we'll show you the github link in a moment because we think it would be great for people to be able to add on whether that be adding a radio interface 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 or a harness to check the device state of advice your instrumenting against so in addition to what matt mentioned on the Auris with firmware development and the state machines we are open to collaborating with anyone who's interested in it that
is the end of all talk although if you really want we can go back and show more
live RF fuzzing but but really there's the github link thanks to Def Con crew and the goons for helping us out and to river loop security crews automation and ionic security for letting us do this instead of being at the office sometimes there's our contact information you can tweet at us with complaints or compliments 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 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 your questions so that we can keep DEFCON moving on time anyone have a question into can can our cheerleading crews 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 I believe Alex he's a little slow sometimes asked us to go back to the beginning and start again yeah let's do that thanks Alex anyone else so just one comment to wrap up as we've kind of worked through this and done more and more work on this we should focus on a or 215 for I think applying this methodology to other protocols is going to rain bugs yeah I think we're gonna find things across all sorts of different protocols so we're excited to work on this and we'd love to get you involved if you're interested so I think we can wrap up thanks very much thanks very much we'll be in the hallway on the left to our chat so thank you
Feedback