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


Hello friends, I'm Jantastic and welcome back to my YouTube channel. I haven't posted here a lot recently But it's my favorite time of the year and we are going to go through react holiday now Let's react holiday react holiday is my 25 day course celebration of react and so this year we're gonna talk about react 18 and all the changes that you need to know about in order to get your app into ship shape for react 18 So without any further ado, let's dive into what we learned this week every week I want to do a YouTube recap of what we've covered in the newsletter. So what's the newsletter? Glad you asked Let's check it out So what we have over here is react dot holiday You can sign up for the email course right here. It looks like it's being the old version's being cashed for some reason I don't know inexplicable Gatsby was really aggressive about caching and so even locally. I'm seeing this this this old version, but It doesn't matter the email thing will go be the same It's just that I'm telling you that this is about react 18 up here You can sign up give me your email address. You'll get 18 lessons for videos and three I think quizzes to test what we've learned. So that's where you sign up That's what we're gonna be talking about and we'll talk specifically today about the first three emails That went out this week first is about the gradual adoption strategy What I want you to know here is is that everything that we cover is covered on the react 18? Working group repo. So you go to react WG you find that react 18 working group and go to Discussions and you'll see everything that we're talking about here now in this email course I've just broken it down for you. So it's a little bit more digestible step-by-step direct Now one specific Article that you'll be interested in is the introduction to react 18 where they specifically talk about the gradual adoption Strategy now what the gradual adoption strategy means is is that you can actually run your app as If it is running in react 17 So if you npm install react beta Then you'll get the latest version the working version of react 18 And if you change no code, it's going to work as if it is running react 17 really impressive But then there's a way to opt into react 18. So super cool. We're gonna cover that in just a second So that is this article you can read it in all the discussion here In day two we talked about versioning versioning is a very important topic to understand if dealing with react So if you go over to npm find the react package and hit versions You'll see these tag aliases that you can use to install various versions of react so if you just do npm install react it's gonna give you the latest version and Let's see what that is. So latest today is 17.0.2 with a grip of installs Now there's some additional tags that you can use to install react and these are what we're gonna explore today so Experimental is the most Experimental edgy they make no guarantees about any of the apis that are in this experimental branch Even making it into a release of react so Experimental means experimental. You never know what's gonna actually come into react from this Now the kind of next most experimental branch is next Okay, so next is whatever the next release is so that could be a beta that could be an alpha whatever the kind of like next version of What we think the next possible version of react is going to be however it can point to beta or alpha So it may be less stable at times depending on what the development cycle looks like now You'll notice right now that beta and next are actually the same version So 18.0.0 beta and then that hash at the end of it So if you use beta or next right now, then you'll get the same thing However, this safest version of these future versions is going to be beta so this is going to guarantee that you you're using a version that's actually intended for eventual release and so it's only gonna have features that are intended for release and have been really pretty well thought through discussed and You know communicated at this point by the community so those are your versions the version that we're going to focus on is beta as I'd mentioned already and That's what we'll use to actually install react 18 beta with all of the APIs in there kind of most stable iteration So we can close that and here you can see we have a react App running in react 17 not 18. So let me reorganize these pains just a little bit and we can update this So this is a repo that I will share to subscribers in the newsletter and right now It has a pretty conventional react 17 setup. So we import react. We import react Dom. We have an app Component and let's see we create a route and then react Dom render our app to the route. So Let's use what we've learned about react versions and update that now So we'll say npm actually this repo uses yarn. It's a create react app. So we say yarn add react at beta and react Dom at Beta So we can hit that and then I'm gonna open up our package Jason while that's running Okay, you saw that happen right away. So we had react 17.0.2 before and now it's react 18.0.0 Dash beta dash this shot and that's gonna change as they release, you know new versions So we have that let's save Well, actually we don't need to make any changes. So we're just gonna say yarn run again or yarn start again and Refresh our app perfect Open this up and see what happened now if everything worked We're gonna see a warning and so this is a new warning specifically for react 18 What does it say react Dom render is no longer supported in react 18 use create route instead Until you switch to the new API your app will behave as if it's running in react 17 learn more And so we can click this link and get sent to the article on how to replace Create route isn't loading for some reason. There we go. Okay, so here we have everything that we need to know to change From react 17 to react 18 now It's important that react 17 still works and you'll see in later lessons how we can use this to our advantage to incrementally migrate our applications But for now, let's just go through and run through the process of changing from the legacy create route API to the new route API We have this here and we're just gonna change something ever so slightly. We're gonna take our route We're gonna move it over here create routes use that new API and Put it there Okay, now once we've created a route with our route element Then we render our application to it So it goes from like a one stage to a two stage process now the cool thing is that we can actually create our route in isolation and then call render on it at different Stages, which is really interesting. So we hit save and then let's refresh our app and that error goes away pretty awesome So that's it. That's all that we did for this week was we talked about The gradual adoption strategy what it means and why it's important. We talked about versions right now We're gonna be using beta It's the safest version that you can be using to be testing out react 18 and we talked about this new create route API So that's really it for this week and if you're following along Thank you so much for following along if you're not yet following on go to react that holiday and Sign up. I'll be on the other side sending you emails and videos and quizzes So thanks so much for being here. You're awesome. Have an awesome holiday season And I hope to see you in those emails. If not, I'll catch you next week on another one of these recap videos See you later


Hi, I'm David Cantor with the Law Offices of David Michael Cantor. A lot of times we get asked, can I still be charged with the DUI if I was never sighted on the night I was arrested? And the answer is yes. Usually what happens is the officer will take you down to a DUI van or the station and draw blood. And a lot of times rather than citing you without knowing what the results will be, they simply did tell you, go on your merry way. This normally happens also with felony or aggravated DUIs. That's where it's a third offense in seven years or if you have a suspended, restricted or revoked license. So don't think you're out of the woods if you merely get stopped and then cut loose. Normally you're going to be charged on a misdemeanor about four to six months later. On a felony it could be six to nine months, even a year later. Now they have up to seven years on a felony and up to a year on a misdemeanor. If this applies to you where you were stopped, they drew your blood and they simply cut you loose, call us immediately because we're going to help you out. Many times we can attack it pre-charged and keep you from ever being charged with a DUI.


For some exemptions, the decision is considered to be absolute and that means generally, there are exceptions, these are not subject to a public interest test to decide if the information should be released. And the most common absolute exemption that you'll see in the wild, so the ones that won't be subject to a public interest test, are section 21, which is information that is already in the public domain, or a section 12 exemption, which is that the cost limit would be exceeded. Oh, it will cost us too much to find this information. So we're going to reject this request and not give you any information at all. We don't subject that to a public interest test because there is a limit to the amount of cost that authority has to bear by answering an FRI request. If they say that this is exceeded, then they don't have to perform a public interest test.


From the CUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE conversation. With Snowflake's enormously successful IPO, it's clear that data warehousing in the cloud has come of age and few companies know more about data and analytics than Google. Hi, I'm Paul Gillan. This is a CUBE conversation and today we're going to talk about data warehousing and data analytics in the cloud. The Google BigQuery, of course, is a popular fully managed serverless data warehouse that enables rapid SQL queries and interactive analysis of massive data sets. This summer Google previewed BigQuery Omni, which essentially brings the capabilities of BigQuery to additional platforms including Amazon Web Services and soon Microsoft Azure. It's all part of Google's multi-cloud strategy. No one knows more about this strategy than Dabanjan Saha, General Manager and Vice President of Engineering for Data Analytics at Google Cloud. And he joins me today. Dabanjan, thanks so much for joining me. Paul, nice to meet you and thank you for having me today. So it's clear that data warehousing is now part of many enterprise data strategies. How has the rise of cloud changed the way organizations are using data science in your view?  I mean, it has enabled things that people couldn't do on prem. For example, if you think about data science, the key ingredient of data science before you can start anything is access to data. And you need massive amount of data in order to build the right model that you want to use. And this was a big problem on prem because people are always thinking about what data to keep, what to discard. That's not an issue in cloud. You can keep as much of data as you want and that has been a big boon for data science. And it's not only your data, you can also have access to other data. For example, your partner's data, public data sets and many other things that people have access to. That's number one. Number two, of course, it's a very compute intensive operation. And, you know, large enterprises, of course, can afford them, build large data center and bring in lots of tens of thousands of CPU cores, GPU cores, TPU cores, whatever have you. But it is difficult, especially for smaller enterprises to have access to that amount of computing power, which is very, very important for data science. Cloud makes it easy.  And not only the big enterprises, everyone can take advantage of the power, the computing power that various different cloud vendors make it available on their platform. And the third, not to overlook that, cloud also makes it available to customers and users lots of various different data science platforms. For example, Google's own TensorFlow, and you have many other platforms, Spark being one example of that, right? Both cloud net platform as well as open source platforms, which is very, very useful for people using data science and managed to open source stacks also makes it very, very affordable. And all of these things have contributed to massive boon in data science in the cloud and from my perspective. Now, of course, we've seen over the last seven months, a rush to the cloud triggered by the COVID-19 pandemic. How is that played out in the analytics field? Do you see any long term changes to that landscape and the way customers are using analytics as a result of what's happened these last seven months? You know, I think as you know, kind of digitization of our business is happening over a long period of time. And people are using AIML analytics and increasing numbers. What I've seen because of COVID-19, that trend has accelerated both in terms of people moving to cloud and in terms of their using advanced analytics and AIML. And they have to do that, right? Pretty much every business is kind of leaning heavily on their data infrastructure in order to gain insight of what's coming next. A lot of the models that people are used to is no longer valid. Things are changing very, very rapidly. So in order to survive and thrive, people have to lean on data, lean on analytics to figure out what's coming around the corner. And that trend in my view is only going to accelerate. It's not going to go the other way around. One of the problems with cloud databases we often hear complaints about is that there are so many of them. Do you see any resolution to that proliferation? Well, you know, I do think one size does not fit all, right? So it is important to have choice. It's important to have specialization. And that's why you see a lot of cloud databases. I don't think the number of cloud databases is going to go down. What I do expect to happen, people are going to use interoperable data formats. They are going to use open APIs so that it's very, very portable as people want to move from one database to another. The way I think the convergence is going to come is two ways. One, you know, a lot of databases, for example, use Federation. If you look at BigQuery, for example, you can start with BigQuery. But with BigQuery, you can have also access to data in other databases, not only in GCP or Google Cloud, but also in AWS with BigQuery Omni, for example, right? So that provides a layer of Federation which kind of creates convergence with respect to querying various different data assets people may have. I have also seen with, for example, with Looker, you know, creation of enterprise-wide data models and data APIs gives people a platform so that they can build their custom data app and data solutions on top of an uniform data API. Those, I believe, are going to be the points of convergence. I think data is probably going to be in different databases because different databases do different things well. That does not mean people wouldn't have access to all their data through one API or one set of models. Well, since we're on the subject of BigQuery, now this summer you introduced BigQuery Omni, which is a database of data warehouse, essentially a version of BigQuery that can query data in other cloud platforms. What is the strategy there? And what has the customer reaction been so far? Well, I mean, you know, as you probably have seen talking to customers, more than 80% of the customers that we talk to use multiple clouds. And that trend is probably not going to change. I mean, it happens for various different reasons, sometimes because of compliance, sometimes because they want to have different tools on different platforms, sometimes because of M&A. We are a big believer of multi-cloud strategy, and that's what we are trying to do with BigQuery Omni. We do realize people have choices, customers will have their data in various different places, and we will take our analytics wherever the data is. So customers won't have to worry about moving data from one place to another, and that's what we are trying to do with BigQuery Omni. You are going to see, you know, for example, with Anthos, we have created a platform over which you can build these various different data stacks and applications which spans multiple clouds. I believe we are going to see more of that, and BigQuery Omni is just the beginning. And how have your customers reacted to that announcement? Well, they reacted very, very positively. This is the first time they have a major cloud vendor offering a fully managed serverless data warehouse platform on multiple clouds. And as I mentioned, I mean, we have many customers who have some of their data assets. For example, in GCP, they really like BigQuery, and they also have, for example, applications running on AWS and S0. And today, the only option they have is to essentially shuttle their data between various different clouds in order to gain insight across the collective pool of data sets that they have. With BigQuery Omni, they won't have to do that. They can keep their data wherever it is. They can still join across that data and get insights irrespective of which cloud their data is. You recently wrote on Forbes about the shortage of data scientists and the need to make data analytics more accessible to the average business user. What is Google doing in that respect? One of our goals is to make the data and insight from data available to everybody in the business. That is the way you can democratize the use of analytics and AIML. And one way to do that is to teach everybody R or Python or some specific tools. But that's going to take a long time. So our approach is make the power of data analytics and AIML available to our users, no matter what tools they're comfortable with. So for example, if you look at BQML, BigQuery ML, we have made it possible for our users who like SQL very much to use the power of ML without having to learn anything else or without having to move their data anywhere else. We have a lot of business users, for example, who prefer spreadsheets. And with connected sheets, we have made the spreadsheet interface available on top of BigQuery. And they can use the power of BigQuery without having to learn anything else. Better yet, we recently launched BigQuery Q&A. And what Q&A allows you to do is to use natural language on top of BigQuery data. So the goal, I mean, if you can do that, that I think is the nirvana where people, anyone, for example, somebody working in a call center talking to a customer can use a simple query to figure out what's going on with the bill, for example. And we believe that if we can democratize the use of data insight and analytics, that not only going to accelerate the digital transformation of the businesses, it's also going to grow consumption. And that's good for both the users as well as business. Well, now you bought Looker last year. What would you say is different about the way Google is coming at the data analytics market from the way other cloud vendors are doing it? So Looker is a great addition to already strong portfolio products that you have. But a lot of people think about Looker as a business intelligence platform. It's actually much more than that. What is unique about Looker is the semantic model that Looker can build on top of data assets, govern semantic model. Looker can build on top of data assets, which may be in BigQuery, maybe in Cloud SQL, maybe in other cloud, for example, in Redshift or SQL data warehouse. And once you have the data model, you can create a data API and essentially an IDE or integrated development environment on top of which you can build your custom workflows. You can build your custom dashboard. You can build your custom data application. And that is, I think, where we are moving. I don't think people want the old world dashboards anymore. They want their data experience to be immersive within the workflow and within the context in which they're using the data. And that's where I see a lot of customers are now using the power of Looker and BigQuery and other platforms that we have by building this custom data apps. And what, again, like BigQuery, Looker is also multi-platform. It supports multiple data warehouses and databases. And that kind of aligns very well with our philosophy of having an open platform that is multi-cloud as well as hybrid. Certainly, with Anthos and with BigQuery Omni, you've demonstrated your commitment to multi-cloud. But not all cloud vendors have an interest in being multi-cloud. Do you see any change to that standoff? And are you really in a position to influence it? Absolutely. I think more than us, it's a customer who is going to influence that. And almost every customer I talk to, they don't want to be in a wall garden. They want to be an open platform where they have the choice. They have the flexibility. And I believe these customers are going to push, essentially, the adoption of platforms which are open and multi-cloud. And I believe over time, the successful platforms have to be open platform and the closed platform. If you look at history, it has never been very successful. And I sincerely think that we are on the right path and we are on the side of customers in this philosophy. Final question. What's your most important priority right now? I wake up every day thinking about how can we make our customers successful. And the best way to make our customers successful is to make sure that they can get business outcome out of the data that they have. And that's what we are trying to do. We want to accelerate time to value for data so that people can keep their data in a governed way. They can gain insight by using the tools that we can provide them. A lot of them we have used internally for many years and those tools are now available to our customers. We also believe we need to democratize the use of analytics and AIML. And that's why we are trying to give customers tools where they don't have to learn a lot of new things and new skills in order to use them. And if we can do them successfully, I think we are going to help our customers get more value out of their data and create businesses which can use that value. I'll give you a couple of quick examples. I mean, for example, if you look at Home Depot, they use our platform to improve the predictability of their inventory by 2x. If you look at, for example, HSBC, they have been able to use our platform to detect financial fraud 10x faster. If you look at, for example, Juan Perez with the CIO of UPS, they have used our AIML and analytics to do better logistics and route planning and they have been able to save 10 million gallons of fuel every year, which amounts to 400 million in cost savings. Those are the kind of business outcome we would like to drive with the power of our platform. Powerful stuff, democratized data, multi-cloud, data in any cloud, who can argue with that? Devanjan Saha, general manager and vice president of engineering for data analytics at Google Cloud, thanks so much for joining me today. Paul, thank you. Thank you for inviting me. I'm Paul Gillan. This has been a CUBE conversation. Thank you.