 Okay, this is Bluetooth smells like chicken and I am Dominic Spell That's me. I am affiliated with Imperial College London, although they do not know that I'm here and So that's the email address in case you want to email me and ask me questions later And you don't get chance at the end of the the talk That's what I mean born and she's tough. I haven't actually tested this yet. Yeah. Yeah, I'm Mark I'm currently unemployed, so No, no affiliation thankfully and I have just finished my masters in computer science and this That was on Bluetooth And that's how I met Dominic and the others And I'm Mike. I I do wireless communication security research for the United States Department of Commerce at the Boulder labs in Colorado and Whoo-hoo. Yeah People's Republic of Boulder Okay And I'm required to tell you that the United States government has no official position on any of this and in general What we're describing today is some stuff that has worked for us and is not necessarily the best solution for any particular problem But we think it's cool stuff and we hope you will too And I guess I'm gonna get up to do that. So sniffing Is that better so sniffing Bluetooth is hard and That's it's why it's an intriguing problem for us. It is something we're trying to make easier Bluetooth as you guys all know is a personal area networking Technology that operates in the 2.4 gigahertz band and it is a frequency hopping spread spectrum system And it is this frequency hopping that is the principal reason that sniffing is hard There are a lot of different spread spectrum techniques like 802.11 for example uses spread spectrum but The particular type that Bluetooth uses is frequency hopping where it just operates on one Relatively narrow band at a time and then jumps around all these different bands It jumps around through 79 channels. Each channel is one megahertz wide and For reference it so basically we have this 79 megahertz band that's carved up into one megahertz chunk and 802.11 B and G Operate in 20 megahertz bands So they sort of spread out their entire in a single packet spreads out across 20 megahertz and and Uses all of that at once But what Bluetooth does is it just uses one megahertz at once, but it jumps around across About four times as much bandwidth as 802.11 does so a radio that can receive 802.11 traffic Only has to be able to process and receive 20 megahertz of bandwidth a radio that that Receives Bluetooth has to either hop around or it has to receive all 79 channels Which is a lot of bandwidth and difficult to deal with The frequency hopping happens 1,600 times per second in most situations and basically Every 625 microseconds the a new packet slot occurs and that packet that entire packet Goes all on one packet. Sorry on one channel and then the next time there's a packet which maybe As soon as 625 microseconds later it selects a new channel Now there is a clock. That's just a free-running counter in every Bluetooth device it's just a counter that up that increments 3,200 times per second and The the hops happen on every other clock cycle The master device in a Bluetooth Pico net provides the clock for the entire Pico net So when you have say a Bluetooth headset connected to a Bluetooth cell phone generally the cell phone would be the master and the headset would be the slave and The once they've synchronized and they're connected into the RRP Kona And at that point they're both using the same hopping sequence because they're both synchronized to the master's clock They're also synchronized to the master's address. The BD 80 dr is Called is the Bluetooth device address and it's a Mac address Every Bluetooth device has one of these assigned and it's it's carved up into multiple sections the the NAP is Called the non-significant address part, which is a little weird because it's the most significant bits but But it's non-significant in other ways In fact, most of the work that we've been doing we've been kind of ignoring the NAP until very recently Because you can do pretty much all the stuff that we're doing Just with knowledge of the LAP and the UAP the hopping sequence is derived from the master's LAP and UAP But not the NAP so the NAP is non-significant for the purposes of a lot of stuff The UAP is the upper address part and the LAP is a lower address part. So the that's just the You know the different portions of the Mac address and the LAP is transmitted I don't need to go into this Yeah, you'll cover that All right, so you want to sniff Bluetooth traffic and with 802.11 You just throw your cards and whichever card you've got into monitor mode or promiscuous mode and Anything on that channel you grab but as Mike said You can't do that with Bluetooth because it's frequency hopping and you need to know which channel you need to be on So the options are hop around and somehow work out how you hop or Capture everything with really wide band hardware that's expensive We we pick the second option because expensive hardware is cool There are there are basically three three devices that you can use there's a protocol analyzer that's about ten thousand dollars It's made by a company who I won't mention right now But that is great for Debugging Bluetooth devices if you've got if you're building a Bluetooth device and it's not working as you think then their product is Fantastic for for what it does, but it's not going to sniff arbitrary traffic from anyone in the area or anything like that It's it's designed for a very specific set of conditions Then there's there's Bluetooth dongles like I mean I assume most people in this room have a Bluetooth device of some sort Otherwise, what the hell are you doing here? They're about ten dollars. You've all seen them. We've got a holo plugged in here. They're USB. They're that big they're all of place and It'll be really great to be able to use them, but they're designed to implement Bluetooth They're not designed to be really wide band They're designed to actually do this hopping that we're talking about So you have to get in them and do all this stuff which mark will talk about later And then there's the the usrp, which is this box at the front Just hold it up. I don't know if anyone's seen one before it's a software to find radio and it's about thousand bucks So you only use the protocol analyzer for sniffing traffic you can either buy it or you can steal it But neither of those are particularly great for for being legal or cheap Which is my preferred method I've already discussed what else it does The Bluetooth devices they're designed to go on one channel. They have this custom firmware. It's a custom CPU in there You really don't want to get into it You can vouch for that software radio Usrp gives us eight megahertz of bandwidth now That's obviously significantly less than the 80 but it's a start So we might got to do something with this and the usrp 2 which came out midway through this work Gives us significantly more and we've incorporated that into what we do But we have to do all our signal processing in software So we don't have a device that we can just tune to a channel and listen We have to do some some serious post-processing on that and that's where this project comes in So one of sniffer single channel. Let's see if we can get some data as devices hot past All right, this is a Bluetooth packet in an oscilloscope. It took me Months six months to find that I spent what I thought was about a month sniffing my own CPU clock, which was 2.4 gigahertz And just an example of how bad at signal processing. I really am I discovered that it wasn't my CPU clock Only what three hours ago and we discovered I was actually sniffing the internal clock of the device I was using to sniff Yeah, that is epic fail But we can get the packet and so then we we have to look at how the packets are formed and this is all given to us in The Bluetooth spec which you can go and download from the special interest group and it's divided into three parts There's an access code at the beginning which lets you Know it's kind of like the the packet header header It lets you know there's a packet coming and it tells you which channel it's on and Which device it's come from or going to then there's a header which contains all the standard stuff you'd expect in a packet header And then there's a payload which carries your data The access code is derived from a 6430 bch code from the LAP which basically means it's an error check on the LAP and Just for good measure. They stuff the LAP in there as well So you don't really have to perform the error check unless you are worried about noise So we can capture a single packet and grab the lower address part as you saw before. That's half your MAC address so Devices in non-scoverable mode don't respond to inquiries But all you need is this MAC address to to talk to them So we've got half of it with one single packet and As you can probably expect all your devices are transmitting stuff all the time They are not quite devices. They don't go to sleep properly So so the next thing we want let's keep working up the MAC address We have the UAP The UAP is a single byte. It's the third or fourth byte depending which direction you go It's not simple. It's not given to us in the packet We don't just we don't just read it out but it is used to initialize the check sums in the packet and There are two check sums in some packets and only one enough is but there's a checks on a header and there's a check on the payload and The UAP happens to be used to initialize both of these check sums So we might be able to do something to retrieve it from these check sums There's an added complication and this is that the Bluetooth packets are what they call whitened and this means that they're Exiled with a pseudo random stream of data to present prevent They said to prevent DC offset at the transmitter Which is not a term I strictly understand But it's something we've got to overcome so You don't have to understand it to break it So that's that's that's pseudo random sequence is ceded by the current clock value at time of transmitting the packet There has been an almost an epidemic outbreak of the stupid over the last 24 hours You you need to police yourselves You are not 13 anymore. You are supposed to be adults And you are supposed to be in the top 10% in terms of IQ in the United States In the last 24 hours, I've been flashing back to DEF CON 9 Stop it We like it here We want to stay here If you do not want to stay here don't come and fuck it up for the rest of us That's all I got to say Okay, where was I? Sorry Whitening. I think you were fucking it up for the rest of us. Yeah. Yeah, I was right, oh Yeah, whitening. Okay, so we take the the six bits of the clock Or six of the bits of the clock there are it's a 27 bit clock loops every 24 hours So we take the lower six bits and we unmoisten now as you may expect We don't know the MAC address of advice. It's a fair chance. We don't know what its internal CPU clock value is so What we do is we just brute force it. It's only 64 combinations. It's going to be fairly straightforward and Then there's some forward error correction, but actually helps us eliminate the noise. So that's great for us So we do the whole thing in reverse. We take those 64 candle at clock values We Unwiten the packet and then we reverse the checksum process and we just run the algorithm in reverse and That gets us out 64 candidate UAPs and it turns out for some bizarre reason it gets us 16 16 candidate UAPs the same 16 candidate UAPs four times and for every packet with that UAP It will get us the same set of 16 candidate UAPs Which is slightly annoying? but not fatal so then we go on and we go through the payload and we reverse the payload checksum and The great thing about that is that it's actually a two-byte checksum So we have a byte of zero and a byte of the UAP so we can be fairly sure when that's unwitened and there's a one in a really big number chance that will get a collision and It's a one in a really big number chance, but it happens. I've seen it happen Hopefully it won't happen during the demo He says jinxing it So hopefully out of that we get a single UAP and I think we're going to give that a try So do you want to run the demo and I'll talk about it? Okay? I will just talk you through what Mike's doing. I Could see it okay So we're basically looking for the UAP by checking the CRC on both the header and the payload and we're doing it This is what happens when you try live demos Sorry Okay Okay, so yeah, that was actually the demo of the the next fantastic thing We're able to do but let's let's start off here if we scroll back up Do you want to just highlight it with the mouse where it found the okay, so just just like this so we went through six packets and Does that make it more readable for everybody? Okay, excellent. We went through six packets and on the first packet We managed to drop from 64 to 54 candidate UAPs and candidate clock values And then we kept reducing that for five more packets and at one point We got a CRC confirmation and so we found out that given that we already know the LAP of our mobile phone the UAP of mobile phone is zero X AF Own it at well and in this particular case We weren't lucky enough to get a packet that had a CRC a payload CRC Not all plac packets have them only certain packet types And so the method that he was talking about in the slide was saying well, you know, we try we try a value We try a clock value We try a UAP and we see if it works and we see if we get a CRC hit and if we do great now we have a pretty definitive answer But in this case, we never got a CRC We never got a payload that actually had a CRC and so we were still able to determine the the UAP not through CRC checks Which would have done it in one packet that has CRC in this case We did it with six packets that don't have CRCs But we were able to measure the relative timing between the packets and so we could narrow down the clock values Because you know if the clock value of one is such and such then x microseconds later The clock value is going to be such and such right so it gives us the ability to take multiple packets and run these checks And narrow it down within a handful of packets rather than just one that we if we were lucky enough to get a CRC right so the the correlation between a candidate UAP and the clock value for the whitening actually gives us the Extra information to be able to do that. So the whitening actually helps us to break it Which one's the Okay, so now we have an LAP and a UAP What can we do? Well, we can sniff packets That's all we need to Grab the packets Verify that the checksums are correct because we use them to find the UAP in the first place So we can use the UAP to find the checksums and we can get six bits of the clock Which is part of the way there, but there's still another 21 bits to go And that's quite a lot to brute force, but as you probably saw from the demo already We were able to get that So if we scroll down in this what you'll notice is that we were able to retrieve the clock value by doing exactly the same thing finding packets measuring the time gaps between them and just Finding a place that fits into the pseudo random helping sequence. Okay We're gonna trade up here and let Dominic see if he can have more success at the demos than I am Than I had we want to show you something that we just learned about the other day the One of the things you can do when you know a MAC address is actually connect to a device and do something like an L2 ping Which is what Dominic's about to do here. He's got a couple of different dongles plugged into Plugged into this laptop and he's using one of them to ping the other one. So he's doing an over-the-air L2 ping It's just a really easy Way to verify connectivity between the two Bluetooth devices and if you know the MAC address you can do this but Josh Wright noticed recently That That you can do this even if you have the wrong Nonsignificant address part check this out. Okay, so now we're pinging an incorrect MAC address You can put garbage in those first two octets of the MAC address there And it doesn't matter because at this layer at this part of the protocol the NAP is non-significant. It's completely ignored So this is kind of interesting because it means that all the work that we've done to figure out what the UAP is It kind of doesn't matter anymore because because you can just brute-force it There are only once you know the LAP there were only 256 UAPs that you have to try right because it doesn't matter what you type in as the NAP and This is the kind of stuff you can learn if you take Josh right out for sushi and But we still like our techniques because our techniques are our way to accomplish the same thing completely passively And relatively quickly like in a few packets that happen in say a few milliseconds Versus a brute force that At least using the command line tools a brute force that I'd ran took like 90 minutes It should be possible to speed that way up But it's it's slower and it's an active attack. And of course, it's nice sometimes to be able to do passive stuff okay, so We would like so far everything we've been showing you is Just using a single channel. We have the we have the usrp up here tuned to one particular channel of the 79 and That allows us to get some packets, which is great it gives us kind of a survey of the traffic that's in the area and That and that's very helpful. It lets us discover the LAP is there. It lets us discover the UAPs But it sure would be nice if we could actually get More traffic and preferably all the traffic that's out there on a particular picot net for example So the most straightforward way to do that to extend to several channels is just to run our Run our tool many times If we take the input from the usrp Dominic mentioned that it that we get eight megahertz of bandwidth we can take that same eight megahertz of input and demultiplex it by just running it through our code eight times with the different down conversion frequency and that allows us to in software tune to those eight different channels and we can run eight separate decode decoding threads playing in and Away we go That technique does work It lets us get eight channels at a time with the usrp. It also lets us get 25 channels at a time with the usrp Too, that's a pretty good chunk of channels Can we get all 79? Well, we could if you happen to have a pile of these things If you have four usrp twos or 10 usrp's you could theoretically do this but realize you're dealing with an incredible amount of Very high bit rate of Stuff data that's coming from the device the usrp or the usrp2 to your host computers And you are going to be you are going to need multiple hosts to be able to do this Roughly speaking we're we get a little better than this but roughly speaking we can decode one channel per CPU core Okay, so in this laptop here that has two CPU cores. I can do this and I can download I can Decode two channels in real time Simultaneously, but if I go more than two channels if I try to do eight for example I start not keeping up with the traffic and so I can't do it in real time. I can post process I can save the raw waveform to file and then slowly post process later and decode all eight channels But if you want to do it in real time You need to have you know in the neighborhood of 79 CPU cores and you need You need a lot of throughput for your your USB buses gigabit ethernet buses in the case of the usrp2 And so forth your favorite slide. Oh, I love this slide So we gave a presentation on this at schmooch on and a question at the end was hey, there's an FPGA on board Why don't you use the FPGA to demodulate the channels and I said that's a great idea. I'll do that Thank you Tony is clapping because he knows the progress of my work This slide is the entire progress of my work Eight yeah, there's a on the USB usrp2 There is a huge FPGA that there's loads of stuff that can be done and there's some guys on Thursday giving a Whole workshop on FPGA design and if they want to get their hands on the usrp2 and do it that would be fantastic But FPGA design is not something I appear to be good at In fact, I appear to be less than good at it and There's also debate as to whether we can before you demodulate you have to filter And there's some debate as to whether we can get the filtering and demodulation to all take place for all 79 channels in the single FPGA and and if we can't do that then It's sort of pointless to do it because we have some techniques that are slightly more intelligent now So it is something we thought about and we're working on please at the end Don't ask about FPGA demodulation because I'll just curl up into a ball and cry Okay, so earlier you may have seen that we I jumped ahead a little bit and I was talking about getting the clock The clock value is used as input to this frequency hopping. So as we hop frequency we We work out which channel we're going to use next by using the UAP Yeah, let's get one By using the UAP the LAP and the current clock value and It's not linear. It is all over the place there. There are some characteristics to it It windows and shifts the window jumps about inside as small band and then and then shifts that band But but in general it's we have the algorithm. So we thought what we do is Take the UAP and LAP that we know generate the entire clock hopping pattern, which is about 24 hours long and Then time the gaps between packets and Work out where in that hopping pattern we are and therefore which clock value we've got by the gaps between the packets and Back at the envelope calculation. I decided this would take five or six packets and in practice It takes a little bit more And in fact the entire discussion surrounding this is how I met Mike and how we got on to doing it Do we want to demo this or are we gonna? Okay, we'll demo it later So ignore that slide So we're gonna combine two demos in one here to save time and give mark a chance to talk the One of the things we'd really like to do is to be able to sniff all 79 channels at once and As we've shown you we have a hard time doing that But there's a trick that we use that allows us to do just that And and what we do is intentional aliasing So those of you who know something about signal processing Probably see this slide and say ah, that's how they do it And I've in the past sometimes explained in gory detail how this works, but I'm gonna skip straight to the The the function exactly the mechanics of what we do Instead of just boring you with all the theory What we do is we have an antenna in the upper Left-hand corner of this diagram. We have an antenna plugged into this daughter board in the usrp2 It's called the RFX 400 2400 and in that daughter board The the signal path goes through an ISM band pass filter This is just a band pass filter that's specially designed for the 24 2.4 gigahertz ISM band right and then it's down converted To baseband so a signal in the neighborhood of 2.4 gigahertz is now in the neighborhood of zero Hertz And then it's low-pass filtered which which is this triangle empty triangle. That's a anti aliasing filter that prevents Different frequencies from clobbering each other in the digital domain And so that happens right before the path goes to the ADC the analog to digital converter Which converts the analog signal into the digital signal and then passes digital signal to the FPGA now The FPGA has to actually down sample or decimate It has to throw out a lot of samples because there are too many to spit over the gigabit ethernet bus The ethernet is not fast enough So it has to throw out a lot of the samples at the ADC gives it and at that point it has the opportunity to introduce more aliases and generally speaking when you're when you're developing a Software radio sort of device You always have these anti aliasing filters here We have to one of them's in hardware on the the RFX 2400 daughter board the other one is actually on the FPGA So one of them's analog one of them's digital, but they're both doing anti aliasing filtering that prevents disparate Frequencies are sorry signals on disparate frequencies from ending up layered on top of each other in the digital domain and Usually you don't want that you don't want those aliases layered layered on top of each other because it creates more interference And when you're trying to decode stuff, but what we do is We remove we bypass the low-pass anti aliasing filter on the daughter board and We modify the FPGA so that it's not doing its anti aliasing filtering either We leave the ISM band filter intact on the daughter board because that gives us only the aliases that we want only the only the ones that are between 2.4 and 2.483 gigahertz and That encompasses quite nicely our 79 channels So we leave that intact so that we don't get aliases. We don't want but we do get aliases that we do want we get 25 megahertz of bandwidth Kind of we get 25 contiguous channels layered on top of the next 25 contiguous channels layered on top of the next 25 contiguous channels and it allows us to decode packets That that are on all these different channels now one of the things That the reason that people usually don't do intentional aliasing is because if you have two packets or two signals on two different channels that are aliases of each other and they happen at the same time Then they clobber each other and you don't and you lose the ability to decode it But we're lucky because in Bluetooth the target network is only transmitting one packet at a time right, so it's only you transmitting on one of those aliases and We don't end up with That that problem of aliases clobbering each other So as long as there isn't too much noise interference because this technique does Amplify the effects of noise interference as long as there isn't too much noise interference This allows us to sniff all the channels of a of a single picot net and If we use the techniques that we talked about to recover the clock and figure out which channel They're to expect a packet on at a particular time Then we only have to use the do the work in their CPU of decoding one channel at a time Even though we're getting 25 channels of bandwidth which is multiplied by the aliasing So really in start from our CPUs perspective world. We only have to decode one at a time and we Figure out but by aliasing Which channel we're gonna look at so let me give you a little demo I'm gonna kind of cheat on this one and do a Demo, this is actually a waveform instead of doing this live I'm gonna use a waveform that was captured So this is just the raw data that was coming from the US RP2 at tour camp actually one of our fellow campers had a we moat and so we were just sniffing the traffic that it was producing and So I'm gonna run this And you'll notice that it found the UAP really quickly because there was a CRC. Hey, that was good And now it's trying to figure out and it's going through all 25 Channels each of which is alias to three or four channels in real life And notice it keeps trying to calculate the hopping sequence and it keeps failing and Restarting and failing and restarting this happens sometimes for a variety of reasons some of which are my fault. I'm sure and the But sooner or later, it's going to acquire the clock and at that point It's going to stop being slow here It is it just got the clock and now it's spitting out packets and notice that it's it's telling you what the clock Value is and it's telling you what channel a Packet occurred on and it's spitting out packets at a pretty high rate actually the we moat in this particular example was Not working correctly. It was like they I don't know he was trying to get him connected to each other but he wasn't actually getting the accelerometer data streaming very rapidly so Overall we have kind of sparse packets But we're getting a lot of packets and they're on the channels we expect them and they're at the times We expect them and once we're to this phase where we're actually decoding stuff And that's the end of the sample when we're actually decoding stuff Like this we're only having to deal with one channel at a time And so it's fast and we can actually do this in real time We're not in real time during that initial period where we're discovering the UAP in the clock But once we have the UAP in the clock we can catch up and do the rest in real time right, so Yeah, as I said, I met Dominic As part of my master's project which was investigating whether there was another way of of doing this because as As I've mentioned, it's it's quite a lot of work to To sniff Bluetooth the There's the demodulation. There's the the aliasing. There's the the large amount of processing required and It seemed that the the thing you really want is a Bluetooth device because they they already have all the all the hardware there There are So we targeted a large manufacturer of Bluetooth devices This is the one who Also create the protocol analyzer that Dominic mentioned earlier and the Protocol analyzer was actually the one that Max Moser a couple of years ago Managed to get running on his own personal Bluetooth device Using a just using the firmware So Yeah, basically they it's CSR they've built a quite a A nice platform for Bluetooth they've it's a soft core For the for the hardware and then there's Firmware on top of that and then on top of that there is a VM So it's it's designed to be extensible at every level and so the The the Bluetooth sniffer protocol analyzer Just updates the firmware and can Can listen to anything that When you have the lap This is this is the con the The layers of Bluetooth. We're actually ideally we're looking for the radio layer, which is what Dominic's done But the the stuff on chip includes the Link manager layer, which is Excuse me Yeah, basically of the all the all the setting up of communications and links and so on is is done on chip And so there are different layers that it Built into the firmware So the the chip itself every Bluetooth chip has sort of the complexity of about two eight six and and it's got a this one in particular has a 16 megahertz processor as well The yeah, so the firmware firmware does the the the link layer and the Mac layer And everything else is done in hardware As mentioned Everybody finds Bluetooth hard, so there's a lot of testing built-in the Bluetooth Bluetooth they had to organize unplug fests for In order to get once they once they done released all the spec In order to get everything to work Because there are there are parts of spec that aren't really Very well-defined And so there it makes sense to put in a lot of places for testing however There there isn't a simple, you know, just read off the read off the air Test mode in any of in any of the test suites. This is probably on purpose because because of FCC certification and so on and and because Yeah, they don't they don't want people sniffing Bluetooth So the the Bluetooth device comes with Various internal tests as well which are not documented But looking at the the firmware you can work out what's going on The my Dominic and my supervisor had actually built a an assembler and disassembler So it was simply a matter of looking through finding the and and and you know finding the tests and working out what they do One of the tests which is particularly interesting is one that is basically just calls mem copy So you can You can get your own code to run on these little computers Just by just by of writing overwriting the return address on the stack and It turns out that there is also an area presumably for flashing of memory that Allow that allows you to run to put code in RAM and then execute from that so I think I can Do a little demo of that if Yeah, so basically you write the code you want into Into this area of memory overflow the stack and you can Say call malloc or something on the chip You can also have a poke around at the internal settings, so there's For instance, that is the page table of the device and Some of these some of these Pages are up for particular areas, so there's there's one that's specifically for Testing one specifically for sending information one for receiving There are various areas for Link management and so on and you can actually watch The information going through This is the This is I think this is Linux doing a Some kind of every now and then ping of some kind But Yeah, there's a there is also a lot of a lot of code in the firmware Which helps a lot with working out what's what's going on And these are all Used to implement the quite complex Bluetooth virtual computer But we don't actually want any of that all we want really is the is the baseband and the code and Looking at it there are there is some it's quite well quite well equipped. There's there's an ADC It's got a USB controller And it uses DMA to send information over the USB bus And then there's of course the the page table which deals with circular buffers So there's there's everything in there to write Without using libraries to to receive using the ADC the problem is the ADC doesn't actually Isn't very useful it only gives you one bit and it takes a microsecond to get that one bit and the symbol rate of Bluetooth is one symbol per microsecond so you You'd need 16 of these devices in order to to just get The normal sorry eight of these devices to get the normal bit rate However in a particular mode Um, sorry in a particular mode it it opens up a memory map register which Conveniently some for some reason there's it's never used, but there's A sample of the demodulated data and this is just Happily sitting there spewing it out at this particular address So what you have to do is read all that information into a buffer Send it back over USB And then when the ADC says that there isn't a signal just stop The original the original plan was to send back information continually, but That doesn't work because of the the DMA controller Completely ruins the timing Um Yeah, so um, I'm just gonna try As with all demos, it's worth noting. This is Defcon and therefore none of them work properly That's why we just ran our aliasing one from file because As we said with that one noise interferes and well you're in like one of the electronically noisiest places, so If we can't get this running straight off, we'll we'll try and keep trying in the breakout room Which I think is room 106 in a couple of minutes so what he's doing right now is generating some test traffic between a couple of Bluetooth devices and and then he's executing his code on the Bluetooth dongle and Retrieving that baseband demodulated data on a single channel and dumping it to a file as Dominic mentioned This device is not working at the moment Mm-hmm It may come up. It has a habit of waiting about 15 seconds, but Yeah, basically The the code that that's running on there at the moment sends it back directly over USB and it occasionally confuses Linux Oh, they're both working now. Let's just give that another go So this is the sync which is receiving everything over USB We'll make the other device send some information and This should now start sampling the data and this information this data can can plug Yeah, this this Sample stream can go straight into everything that Dominic and Mike have done Yeah, yeah, so we're actually able to use the GNU radio libraries to do clock recovery and Bits slicing and then just pass this in as if it came from the US RP So the software just doesn't well the idea is the software doesn't care what kind of device you sniff the traffic with Whether it's the $2,000 US RP to or just a Whole load of USB hubs and 79 different Bluetooth dongles And what's actually on screen now is the raw waveform that was collected from the from the dongle But it is demodulated. Yeah, that's right. It's demodulated. It's it's been run through the demodulator But it hasn't been run through the decoder yet. So It's it's something that we can take and plug into the software that Dominic and I have written and actually extract packets from so yeah, just just Just here is the beginning of the Bluetooth packet and then this all of the rest here if if you plug it in will will Will give a Bluetooth packet and the Right, so the significant advantage of this is that it only costs $2 instead of a thousand It doesn't have The advantage of the US RP of being able to sit sniff all 80 channels at a time but in order to do that all you really need is 79 dongles And a lot of USB hubs if you'd like to pass your dongles and USB hubs to the front Give it a try and then of course the fact that Bluetooth is only transmitting on one channel at a time helps Because again the the 80 Devices sending back information of USB wouldn't work But actually sniffing on one channel seems to work well enough The randomness means that it if you if you listen on one particular frequency you You get you get even proportion of packets Yeah Really really quickly because I've got about 30 seconds left the security implications are non-scover mode doesn't exist Did they're lying? feel free to argue with me on this one, but By all means if you've got your Bluetooth devices in non-scover mode just turn Bluetooth off. It's using on the battery anyway It's not worth it. It does open the door for active attacks, which we haven't done yet, but that's the plan at least at some point And we have made some interesting observations regarding encryption, which we will Have to detail next year at Defcon So we'll be in the breakout room 106. Yeah, we'll be in 106 Anyone wants to we'll try and get that demo working all those demos working properly and we'll take questions and answers in there But that's the address of the code if you want it