So, as you may have guessed by now, this is real-time Bluetooth detection using Blue
Hydra. It feels very real-time, doesn't it? We're going to go a little faster than we
planned, so we're going to jump ahead here. Oh. Try to page up and down. All right, I'm
Granolox. I work at Pony Express. I've been there for about as long as Pony Express has
existed, and I primarily focus on device detection, looking at different kinds of devices
that we see in the environments that we're monitoring for people. That's how I got involved
with this project with this Mr. The Plague Looking Guy here. So we saw that we needed to see
more Bluetooth devices because we were barely seeing anything that was out there in the
world, and this is how this came about. Whoo! I'm a very calm Zero Chaos. A lot of you might
know me. I do wireless stuff, and please stop calling Wi-Fi wireless. Those are not the
same things. I like anything that you're in touch with. So, I'm going to go ahead and
show you some of the things that you're not touching because it's way cooler to hack things
that you didn't touch. Wires are boring, and wireless stuff is fun, whether it's ham radio or
Bluetooth or Wi-Fi or whatever. So, free plug for the wireless village. Come by Skyview
1 on 26th floor of the other tower and hang out with us and do some real wireless stuff. So, what
is Bluetooth, right? Bluetooth is cheap. It's meant to replace the cables that fail us
horribly while we're trying to give our presentation at DEF CON. That's why I'm trying to get our
but that's really what it's for it's it's not for high bandwidth applications it's not intended for
that originally it's just intended to replace the cables you don't have to plug in your keyboard
or possibly your your monitor or possibly i don't know i guess your cell phone it's not meant for
much right what it does is frequency hopping spread spectrum it hops 800 times a second
to try to get away from interference and to not interfere so much with other devices so you're
actually going to be hopping constantly all over the spectrum which as you might imagine makes
monitoring it a lot harder and that's really why there's no monitor mode on these these pieces of
hardware is it's very difficult to monitor this in the first place and the target price of bluetooth
radio is about five cents and none of its normal operation requires that kind of monitor mode so
why why would you ever do that increasingly
component cost is just not something that's typically done for fun so they didn't do it so no
monitor mode means sad face now bluetooth is divided up into three basic classes class one is
the hundred milliwatt which is about hundred meters is what they expect the distance to be
in fantasyland those are high powered devices the senna dongles that pony express likes to use
they're really nice to have if you actually expect a class one to go 100 meters you might
be on another planet but class two is what you normally run into it's
your your bluetooth on your cell phone your headset your laptop those are 10 meters which
30 feet away for like something meant to connect your keyboard is pretty good right that's not
really a problem for what you're doing from my pocket to my earpiece is only about two and a
half feet um sicilian it's the best we could do it's a little farther for him but still well within
30 feet right it's not really a big deal to have low power bluetooth if you get a really bad one
that's called class three that's one milliwatt and that's the only way you're going to get a really bad one
that's why sometimes you buy the really cheap bluetooth headset or it was really expensive but
it was made really cheap from your pocket to your ears not all that possible because it's actually
only going to go about a meter and you're basically maxing it out if you're a six foot tall person
this is what bluetooth looks like on spectrum uh we we've got the really pretty 3d
waterfall that honestly if i could put this as a video it looks so much cooler
but since i can't do a live demo to start with we'll just go ahead and be happy that i've got
this at all
this is a standard uh fast for your transform uh waterfall display but you can see all of those
little blips are bluetooth this was actually us rocking out in the wireless village setting stuff
up last night uh this is this is high bandwidth audio this is this is very high quality as you can
see very very little actual data is being sent on a network where you would have like a large
wi-fi network possibly right in the middle of this you'd actually see all the bluetooth go below and
there's no wireless internet there's no network connection to get out but that's a little
i mean we have an amazing radio radio you could just record this radio radio using what's called
adaptive frequency hopping it's basically just going to avoid interfering with the wi-fi and avoid
being interfered with by the wi-fi and that's really a function of just get out of the way
because you're the lower bandwidth guy and it's easier but again that makes it a lot harder to
sniff bluetooth directly and that's why those radios just don't have those kinds of functionalities
bluetooth classic this is the stuff that you all know and love you probably are using uh everyday headsets uh
things like that. The security for this stuff is really, really simple. It works on a process
called discoverable or not discoverable. If it's not discoverable, that's the mode it's supposed
to be in all the time. It's supposed to be just not visible to the outside world, as it were.
It's supposed to be already configured, already did the key exchange. People compare everything
to Wi-Fi. I can't count the number of times I've walked in for Wi-Max recommendations or
Bluetooth recommendations. It was a set of Wi-Fi recommendations where they did a search and
replace and changed Wi-Fi to Zigbee or something stupid like that. It's like, no, no, no. That's
not how this works. Bluetooth, when you disconnect, doesn't actually terminate the
authentication. The key material is saved on both ends. Those are kept. You don't have to
re-authenticate them. You don't have to re-authenticate them. You don't have to
type the pin in every time you use every piece of your Bluetooth hardware. The pairing is part of
you turn into discoverable mode, you find the device, then you pair to it. Kind of like a
marriage, you can let people know that you're married, but the pairing you kind of should be
doing in secret. You don't want people to be observing that key material because that's all
of your security right there. For a really great primer on how that works, Mike Ryan gave a talk
at Sprint. He said, I don't want people to be observing that key material because that's all
you should be looking at. If you don't know all of it, just hide it. If you're talking to a
computer, I highly recommend. It was called, how smart is Bluetooth smart. It goes over how all
pairing and stuff works. It's really eye opening to know that if you're not pairing in a Faraday
cage, you probably should start. Bluetooth classic is all of the security is based around
pairing in secret. And if you are not paired to a device, it's a lot harder to find it. We'll
get into how we do that, and it's fun. Bluetooth low energy, there is probably way too many of you
that have this on in the room. If you're me, you'll have to take it out and have some fixing on the
uh all of you with a fitbit or a smart watch or a salt card to authenticate to your cell phone for
you uh these bluetooth low energy devices are the the really popular stuff now and that's kind of
why we ended up writing this tool the bluetooth stuff has been exploding and we couldn't see it
and that was really terrifying for us and when we started building this and seeing just how much was
out there it became a much bigger priority to work on this because we thought it was cool
so bluetooth low energy unlike bluetooth classic has three discoverability settings uh general
discoverability limited discoverability and non-discoverable uh what's funny is is it really
doesn't matter because the way this works is you send out an advertisement and you say hey i'm
invisible and you send it out about four times a second hey i'm invisible hey i'm invisible ham
invisible ham invisible and the way the spec is written you drop those packets that's what you're
supposed to do
i'm glad you all feel the same as me about how great that is uh some devices don't advertise
if you're wearing a fitbit you don't own one of them if you're wearing pretty much any of the
fitness bands fitness trackers most of them just don't do it the more high-end devices a lot of
the smart watches they don't advertise unless you go to the settings menu and mark it discoverable
and that kind of stuff they're actually half decent but we still do see them quite a bit
because sometimes it loses the connection to the phone
decides to go to the settings menu and mark it discoverable and that kind of stuff they're
going to do if you go to the settings menu and mark it discoverable and they'll add the
settings menu and mark it discoverable and that kind of stuff they're going to add the settings
the phone can find it again and things like that so bluetooth proliferation uh there's a whole
bunch of random iot iot iot iot iot iot iot iot are you all drunk yet good okay that's enough of
that garbage wearable stuff all around you bluetooth low energy which was also called bluetooth
smart although it is not actually lower power transmit and receive it's designed to be lower
power consumption it's trying to be as low as possible it's trying to be as low as possible it's
to do deep sleep cycles and things like that to avoid burning all that power. So all of the
wearable devices, the smart watches, the fitness trackers, they try to do that. So here's just a
really quick, terrifying set of numbers. You know, Fitbit last year sold 21 million devices.
Xiaomi did 12 million. Apple did 11.6. I'm reading all three of those while I eyeball my cohort just
so he knows that Apple's in third behind China. Anyway, point is, total 78.1 million wearable
Bluetooth low energy pieces of unsecure garbage, mostly. It's terrifying, right? We have all these
devices with us all the time. I'm wearing three of them. Try to count them while I'm standing here.
But seriously, we have so much of this and we're not looking for it. It's interesting, if nothing
more than that. But you can get a lot of fun info from it. So I think it's even better.
It's even more interesting. Prior art, I'm going to gloss over pretty quick because I'd like to
get more time to my cohort. But we looked at a bunch of Bluetooth tools that existed. Red Fang is
a Bluetooth discovery that does brute forcing of MAC addresses. Hey, it's not discoverable. I'm
going to ping every MAC address on the planet and try to find it. That's one way to do that. We
went with a different way. But that's one way to do that. BT Crack and Crackle are pin
crackers. Those are trying to break the authentication between the Mac addresses. So
you can see the devices. And then Blue Snarfer is an older tool meant for like dumping phone
books and SMS messages off of phones. None of this was in our interest. What we were trying to do
was discover the devices that were in the area, fingerprint them, track them, see when they show
up, when they leave, have the ability to find them physically and meet space. And that's really
what was interesting to us. So like all this stuff existed. Only Crackle really worked on
Bluetooth low energy stuff. And none of it was really all that interesting to us. Bluetooth
discovery is a really interesting tool. It's a really interesting tool. It's a really interesting
tool. Blue Log is a great tool. But it was written back when there wasn't Bluetooth low
energy. So it doesn't support Bluetooth low energy. So it spams out a bunch of really useful
logs constantly at a terrifying rate. And we didn't find it all that useful. BT Scanner was an
absolutely beautiful app. Kind of like Kismet but for Bluetooth. Worked really well unless you
pressed any key and then it would crash. It's been unmaintained. It's not their fault. It's been
unmaintained since about 2003 as far as I know. So it's a really good tool. It's a really good
app as far as I can tell. So no LE support on that either because there was no such thing as LE.
And it had a really neat GUI. And we really liked it. And maybe if either of us could code in C,
we would have picked it up and started working on it. But as it turns out, I shouldn't program.
And he's better? Arguably. Arguably better. Useful stuff. As it turns out, if you're going to
stand on the shoulders of giants and you're working on Bluetooth, the Blues team is
probably a hearty good place to start. So Blues is the library for Linux that runs all the
Bluetooth stack. And they not only have a functional library and workable tools, they have
documentation. And examples. And unit tests that work 60, 70% of the time. So it's really,
really good stuff. I'd like to thank them for that. And there's a thanks for it later. But
really, thank you. So HCI config is the main controller. Brings the card up, down,
resets it when it goes out to lunch, which is pretty often because it's 5 cent hardware. I mean,
they charge you a lot more for it. But that plastic has got to be really expensive because the chip
sure ain't. HCI tool is going to discover your classic devices. HCI tool scan will look for
classic devices in discover mode. HCI tool less scan, LE scan as we were calling it internally,
works but it's really hard to parse. And when I told the Blues team what I was doing with them,
they were like, oh, my God, stop. Stop now. Never do that again. You're an idiot. And I said,
okay, cool, but could you elaborate? They're like, oh, all those tools are completely out of
date, unmaintained, and probably will crash your kernel. Oh, thanks. So they told me about their
test scripts and some of their documentation. And we moved on to the test scripts, which was
Blues test discovery, which was a thing that they did in Python that shows how to use the
debus interface and a bunch of internal libraries to
actually do proper detection that doesn't crash your system. The Bluetooth dongle still crashes
relentlessly, but the kernel doesn't. And that's definitely an improvement for those of you who
have never crashed your kernel while giving a presentation. So the problem is, of course, being
that the Blues team writes the main libraries for Linux, it hides some LE devices. The
non-discoverable ones, it just goes ahead and throws out the responses and things like that.
But what it did for us is it helps us to talk to our customers. So we're going to talk to our
Bluetooth card. It taught us how all of that works, and we used all of their documentation and
their API calls and took their huge bit of code and, like, ripped out the six lines we needed and
said that we modified it. And that taught us how to see discoverable devices. But discoverable
devices are only so much of the fun. I mean, granted, LE stuff is noisy as sin, but we wanted to
see other stuff. So we fell back to our good friends at the Ubertooth team, and they have a lovely
piece of hardware. I think it's about 100 bucks, something like that. You can buy them basically
everywhere. But Great Scott Gadgets makes a product called the Ubertooth, and this is a true
Bluetooth basic rate sniffer. It sniffs basic rate, which is kind of like to Bluetooth what 802.11b
is to Wi-Fi. There are faster speeds, but somehow people always send stuff at slower speeds, so you
can see it. They can't sniff Bluetooth EDR, which is Bluetooth 2.0 enhanced data rate with these,
but that is what they're doing. So we're going to take a look at some of the features that they've
added to the Ubertooth. And that hasn't actually been much of a problem for us, because everything
kind of sends packets at a slower speed at some point fast enough that we feel happy. So
Ubertooth Scan was the program we were using initially. And what it does is it sniffs on one
channel, and it looks for any devices that are communicating. In Bluetooth, you only transmit the
lower address part of the master device when you are having a communication. And who it's from and
to is dependent on the time slot. So if you're using Bluetooth, you're only going to be able to
send a message from master to slave, from slave to master, back and forth. And what this allows us
to do is we can sniff the lower address part, and then you grab some information from the header,
and you do some math after a couple of packets. You can figure out the upper address part, which
is enough to ping the device, and that's just what Ubertooth Scan did, is it would then take
your Bluetooth dongle, and it would query it for a name and information and give you a bunch of
information on the device back. Because we had all of the test discovery stuff already, and it was
working so well, we wanted to not have it interrogate the Bluetooth device like that. So we
talked to the Ubertooth team, and they introduced the last thing on their minds, which was
Ubertooth-RX-Z, and they gave us that flag where it just does the sniffing part, and it doesn't
do anything else. And then we parsed it internally, and my friend Granolox will explain that.
Right about now. Okay. So I'm actually going to go through and talk about the tool that we made,
and how it functions. I mean, it is a little bit more complicated than what I was talking about.
We are open sourcing it as part of this, and so I'm actually going to talk through the internals
of the tool a little bit, with the hope that people will be able to read through it and look
through it and, you know, contribute back to it, ideally, would be great. So the primary goal
that we had was to create an AeroDump-like interface where you can see a live view of
Bluetooth devices around you at any given time. We also wanted to support Bluetooth low energy,
because the existing tools that did something like this did none of that. And that was a really
important thing for us, just given how much device proliferation we have been seeing. So we
wanted to make sure that we were being on the low energy side of things. And again, the second
point there, find as many devices as possible. That was really the goal. But a bigger part of
that was to find them as quickly as possible, because a lot of the low energy devices are
things like mobile or wearable devices that are on people that are moving around or on cars or
vehicles or on trolleys with beacons, and so they tend to move past you very quickly. And if you
don't pick them up when they're there, you're going to miss them entirely. We opted to have a
database back end for the purposes of persistency. We wanted to be able to turn this thing
off and then bring it back up later and be able to correlate devices that we saw back to what we
had previously seen. And the database allowed us to do that. And another goal, going back to sort
of the standing on the shoulders of giants, is to really minimize the amount of direct hardware
interfacing we're actually doing. This really let us move a lot faster on the development side
of things. And it allowed us to kind of keep things as simple as possible and use the tools
that exist without trying to reinvent the wheel. And we're not at all focused on cracking or
brute forcing or attacking Bluetooth as a tool, at least at this time. In terms of the design
logic, it's primarily written in Ruby. It's 95 percent Ruby. There's a little bit of bash and a
little bit of Python. The bash is mainly there to manage the interface and to shell out to run
some of the third party tools that we're relying on. What he's trying to say is we're sorry in
advance. Yeah. And then the Python, yeah, and then, yeah, if you read it, good luck and I'm
sorry. But the Python side of things is just the test discovery script using the blues, like the
pi blues library that Rick mentioned. So we built it on top of these existing tools as much
as possible. This helped us develop very rapidly and we modified the tools as we needed, but
again, to minimize the use of hardware, we entirely relied on them where we could. So at a
high level, what we do is we have a number of discrete threads, like Ruby threads running in
the background, which are doing each of our different tasks and then everything gets boiled
down into a single data processing thread. For the database, we did use SQLite initially and
SQLite, if anyone's ever used it, which I'm sure you have, is kind of trash. It worked for our
purposes, but one of the problems with it is it's extremely blocking and so if you try to access it
from multiple threads, you're going to end up with a ton of write lock contention and
everything's going to fall over. So we ended up boiling everything down into a single thread for
processing the data, which ultimately served us pretty well for reasons I'll probably explain if
I have time. Before we get into the threads, I think the tool that we need to talk about is
btmon, which is also part of the Blues library and this is a tool which is, the whole Blue
Hydra suite is dependent upon. And so there is no true monitor mode, which is say like
monitoring RF for Bluetooth, like we might have with Wi-Fi, but what it does is it monitors the
interactions between the operating system and the adapter, the Bluetooth adapter. So as
commands get sent to the adapter or the adapter receives packets, it'll summarize, btmon's able
to summarize those messages into a basically a long stream of whatever the
heck's going through the adapter. And we use that as our primary point of contact for
getting data out of the interface. It's reasonably parsable, it is text output and so it's a
little funky and I'll show you the output in a second here, but it wasn't too bad to handle the
parsing. One of the things that's really powerful about using btmon like this is we were able to
throw all kinds of different commands such as what Rich Zero mentioned. Sorry. Nice catch.
Yeah, nice catch there. You know, we could run the HCI tool commands or the L2 ping
commands and they are the test discovery as well and all of that would come streaming out of
btmon in one place. It also supports multiple Bluetooth dongles and right now the actual
service isn't supporting multiple devices, but we plan to add that in the not too distant future.
So with btmon, this is the, you can see the output here, this is a single message coming out of
btmon. It's an LE advertising report, so this is an LE device advertising its existence and the
way that we use it is we have a single thread that executes and filters the messages coming out
of btmon and breaks them up. We push them over to another thread that basically buffers
them by device. So we'll see same device, same device, same device, same device, different
device. When we get a new device, we flush that out to get parsed and processed and we start
buffering the new device that we're seeing data about. Alright, so the next thread that's
really significant and this is where a lot of the actual work is done is the main discovery
thread. So this thread is responsible for running test discovery commands and it also feeds
off a number of cues which different parts of the system feed into that tell it who it needs to
gather information from, who it needs to ping. The L2 ping command is very useful for us because it
allows us to test if devices are still present even if they've gone out of discoverable mode or
even if we never saw them in discoverable mode such as with an uber tooth. It's also responsible
mainly for the info gathering and the test discovery script will see the classic mode devices
as well as the LE advertisements. Nothing, none of the commands that get run in this thread we do
anything with. It's just a simple, simple, simple, simple, simple, simple, simple, simple, simple,
simple, simple, simple, simple. It's just all coming out of BTmon on the other side of things.
We do do error handling here so you'll see a lot of error handling if you start reading this
code but that's just to make sure. We do some error handling here and that's mainly, mainly
where we're error handling. So if something goes wrong with the card or any of the commands
we'll catch it here and handle it here. So the uber tooth thread also exists. It will only
start if you have an uber tooth device plugged in and it is completely optional. It does not
replace having a conventional bluetooth dongle which you absolutely need to run this system. The
system still relies on a traditional Bluetooth dongle. We recommend the SENA dongles that
Pony Express ships and they're quite robust. With the Ubertooth thread it's running the
Ubertooth Rx command on a slow loop and it bypasses BTmon entirely and ships that
information straight into the processing queue. So with the data processing thread this is
kind of the core brain of what we're doing and it is mainly, excuse me, it's mainly
responsible for updating and creating the records and sort of tracking what devices we've
seen but it also operates as a feedback loop to the rest of the system populating the queues to
say you need to test this device, you need to see if this is still present and this allows the
discovery thread to do what it needs to do to kind of see and gather the information as
quickly as we can to, you know, gather info about devices before they pass out of our range.
One of the interesting problems we found here was the actual device correlation of Bluetooth
devices. So we assumed initially and pretty naively
that we'd just be able to see MAC addresses and say, okay, this is the same MAC address that we
saw previously, it's the same device. That falls over pretty quickly. Initially it falls over with
the Ubertooth because the Ubertooth will only see the upper and lower address parts, which is
the last four octets of the MAC address. So in the example here you can see a device with a
physical address of Dead Beef Cafe and an Ubertooth will just return something something
Beef Cafe and have no sense of the vendor. If you want to do an OUI lookup you wouldn't be
able to do it off this alone. And we're never able to get the rest of that address, the
complete address, with an Ubertooth. So we are able to, however, zero pad it or pad it with any
arbitrary hex and send it back out and ping those devices and they will respond to their upper and
lower, the UAP, LAP, upper and lower address parts. And the non-significant address part,
which is the first two octets, is totally irrelevant, except for doing vendor lookups. So if
we then see that device come into discoverable mode and we see its full address, we're able to
backfill and kind of fill in the addresses that we didn't see, which we initially saw with an
Ubertooth. Another type of device correlation is the fact that if you have an Ubertooth device,
you don't have to look up the address. So the last type of device correlation we're able to do
in here is iBeacons. iBeacons are capable of rolling their MACs very aggressively. They change
their address quickly. And they don't always do this, but they can do this. And so we're not
able to consistently rely on looking it up by the address. So we were able to carve out some
information out of btmon, specifically the proximity ID and the major and minor numbers,
which we were fairly consistently able to track iBeacons even as they rolled their MACs and
moved around the space. So the last thread that's kind of worth mentioning, and this would be
our demo, although I don't know, we're probably not going to have a demo because of this, we
have some screenshots, is the sui thread. And it's the command line user interface, which is to
say it's the arrow dump style output, which shows you, which is really a live table of the
devices that you're seeing around you at any given time. So it's simple, it's not curses or
anything, but it is sortable columns and you can kind of add and remove columns as you need to
get the information that you care about for the devices.
So that's the main bulk of the internals of the tool. And we were going to go, I think, next to a demo.
And we're going to do it live. Yeah, let's do it dead. So we're going to do it dead. Yeah, so I want to
apologize because after going through six laptops, we finally got something that works and I'm not
unplugging it right now to see if we fixed the wire or if all five laptops before this one didn't
work. We're going to after everything else. So I don't have to switch back and forth and break it again.
So I'll show you the screen shots and if we're really lucky, I'll switch to a live demo
afterwards. This is SUI. What it is basically is, as Granulok said, it's roughly an arrow dump
style interface. We've got the address, the version, what version including like 4.2 will
actually show up here on the devices to tell us. The RSSI names. Manufacture is an overloaded
field. So we grab a bunch of different information from different places in the Bluetooth stack.
And we kind of put the best thing in that spot. And then range is an iBeacon specific thing. The
iBeacons actually give you a calibrated TX power of what they expect the signal strength to be at a
meter away. So you can use that to magically estimate the distance very, very reliably. So as
you can see, these were all sitting on top of the Bluetooth dongle when we tested this. This
interface is pretty simple. And if I'm lucky, I'll get to show you. But you can see this little
carrot right here. This is indicating that this is sorting ascending. It can also sort descending.
You can reverse the sort. And the other cool thing is you can change which column it is sorting by.
You can also change which columns are available. So this is the default view of columns.
Manufacture and range being the two interesting ones. This is the iBeacon specific columns where
we add in the proximity UUID, the major number and the minor number. These are the things that
make iBeacons unique.
So its proximity is basically the company and then major is like it's in this store number. And
then the minor is like this is in the fruit stand. So that when you walk up to the fruit stand,
you've got the, you know, grocery store app on your phone and it says, oh, dollar off bruised
apples or whatever it is. This is the company display information. I find that a lot of stuff
has interesting things in the company and company data field. And so we added that as a
secondary display while debugging some stuff and left it in there because we thought it was
useful. So you can change the column sets. You can change the sort. You can change, you know,
up or down on the sort as well. I think it's worth noting and we may or may not be able to show
this given the functioning of the demo, but this is a fraction of the data we're actually
gathering about these devices. There's a ton more information being stored in the database.
This is what we consider to be the most useful,
convenient information when you're looking at a live view. But if you go back and pull data out
of the database, there's a massive amount of information about these devices. Thank you. So
where do I get it? On GitHub. Pony Express slash blue underscore Hydra because go blue Hydra.
Hail blue Hydra. You can download it. There's a list of depths in the read me. And then you can
run it straight from the git checkout and there's no problems with doing that because,
shocker, that's how we developed it. It doesn't have a lot of information in there. You can
download it. It does run on Cali because we developed it specifically to run on Cali Linux,
which is what the Pony Express sensors run. That said, they haven't packaged it yet. So you just
have to install the dependencies and all that stuff manually. Or especially if you're competing
in the wireless catch the flag this weekend, you can just download Pentoo's latest release and
it's already on there. And gosh, I developed blue Hydra. I added it to my distro. I wonder if
there could possibly be any contests around needing it desperately. Could I track somebody with this tool?
That's a very good question, sir. Shut up. Questions are later. I mean, yes. Yes. Thank you for
your question, kind sir. So our conclusions were basically we found a lot of old Bluetooth stuff
because when Bluetooth came out, it was really cool to hack Bluetooth. And then apparently it
wasn't cool anymore. But somehow it became cool to have nine Bluetooth low energy devices on your
phone at all times. So we thought it would be cool to look at Bluetooth again. We took a really
simple idea that had Gabe very mad at me for a very long time because it turns out it was, hey,
there you go. Granulox. It was harder to do than expected. And, yeah, so we both suck at
programming, but he sucks a little less than I do. So it was surprising to see just how many
devices were out there. I can't count the number of places I went, like Hagger conventions, where I
just saw hundreds of devices. I can't count the number of devices I went, like Hagger conventions,
where I just saw hundreds of devices inside of one room and wondered why. Just why. So I'd like to
thank DEF CON for telling me that the projector was VGA and then providing HDMI that doesn't
work. Though I would sincerely like to thank the CFP selection crew, you know who you are, for
letting us present. We really do appreciate that because we think this is really cool and we
really hope that you do too. We'd like to thank Punish for the presentation. We really do
appreciate that. We're so grateful to the MLS Express for paying us to build this and then
letting us convince them to open source it, not just open source it, but put a BSD license on it.
Coconut Picard for helping us release this code as BSD. Our boss got a new Hagger name and
that's what it is. So, yeah, if any of you ever see the VP of engineering, you can call them that
and don't tell me, don't blame me. The Uber Tooth team for being awesome. Not only did they
implement a new feature for us but they told us how a bunch of stuff worked and helped us a lot
and the blues team for their very efficient german making fun of us which helped us to do what we
needed to do that was really really great of them so q a will be in room the bar at the bottom of
the escalators there are other people that will be taking over this place in about eight minutes
and that leaves me for yelled out question and answers while i try to get a cool demo running
so that those of you that prepped funny bluetooth device names don't feel like you got cheated