All right. So I'm here to talk about BlueCat. Who's heard of BlueCat so far? Awesome. Okay.
So pretty much I'm a, my name is Joseph Paul Cohen. I'm a PhD student at UMass Boston.
So I do, it's kind of a side thing, basically like a cybersecurity computer science education.
I do a lot of machine learning and computer vision stuff. So it's kind of
dual tracks, right? So this is, this is, this is the fun stuff.
So I want to just have some questions to kind of gauge the audience, right? So how many of you
guys have used the Bluetooth API, whether it's Blues or OSX or Windows or whatever?
Okay. So it's not that many. Okay. Who's used Netcat to talk to a web server?
All right. So that's, that's half. Okay. Who's created an outrageously complex
fast script that, to do some task? Okay. So these are kind of all going to come together
in this talk.
So it seems like everyone's kind of well-versed in that. So the overview of the sections of this
are going to talk about streams and how they're awesome and fundamental, right? And then how
BlueCat, how you can replace BlueCat in line with wherever you use Netcat, right? So any
situation you can think about using Netcat over an IP address, you can use BlueCat. You just
kind of replace the IP addresses with Macs, right? And then you just have to be in range.
And we also have BlueCat as a Bluetooth end map. So it's like a, we do scanning and,
I do scanning and service discovery functions, right? And then basically I'm only going to talk
about RF com and L2 cap. Those are the only things that really like are understood by BlueCat
because they kind of make sense. You have port numbers and you can, you can talk to them
directly. And then we're going to look at some devices with BlueCat and see like how you, you
know, examine other devices with BlueCat. How to make, how to prototype some stuff really quick.
Some stats I've generated while scanning. And then if we have time, the architecture of how BlueCat
works on like tons of architectures, right? So first, streams are awesome, right? So I hope
everyone agrees. You can take something like a file and you can turn it into a stream and you can
pipe it into something like VLC and you can kind of abstract everything that has to do on a
computer to stream, to a stream. So once it becomes a stream, really don't care where it goes.
But, you know, we can, we, we use streams, you know, we, we, we, we, we, we, we, we, we, we, we, we, we, we, we,
we, We can use streams every day when we was to saat to PalTalk. So every time you go on ..
Ha, ha. Okay. I'll just get . Okay.
Whoa, BlueCat was supposed to, was supposed to be on, but I was, I didn't want to broadcast my
MAC to everyone. But I did when I was pairing, so anyway. So we have a computer and it turns into a
stream and then you can go to Tel Pal Talk. And then back at so that's how that kind of
communication works.
Yeah.
Like most –
things are based there. So you can put some kind of block in
the middle and then you don't care what happens on the other
side, you know, inside this block, right? The computer just
talks to this thing and at the other side it's going to come
out to Peltalk. And then from that side, the responses go into
this, you know, blob and then come out the other side to you.
And you don't really have to care what's inside of there,
right? It gets subtracted with all the layers, right? So the
Internet would work. You send some stream, it goes through a
series of tubes and then it comes out the other side and you
really don't care. So you can take some really complicated
process like routing all the way across the Internet and just
forget about it, right? Have someone else kind of take that
initiative and you just deal with high level application
stuff. So you can extract really complicated things and
just kind of ignore that they exist no matter how dysfunctional
they are. Okay. So to really appreciate the usage of just
talking to these services, right, we can take a look at HTTP.
So I just want to go over the simple, make sure everyone is on
the same page. So HTTP is pretty awesome, right? It's simple,
it's human readable. You can kind of intuitively know what's
going on just by reading like some traces, right? Debugging is
easy. You can kind of look right at it in any kind of debugger and
you still don't have to read the HTTP spec. You can see all this
stuff. You can encapsulate it, write the stream and anything
and you can add custom stuff, right? So it's not really so
picky.
It's very forgiving. So here's a diagram I didn't make. From a
browser you can send an HTTP request to a server and you get
a response and these are just like you can think of it as a
tiny text file, a bunch of streams, a bunch of strings and
then you get back the same thing, right? And that's the
basic interaction, right? So you can experiment. You just type
the string get and then you get back whatever response. So
here's one for DEF CON, right? So we do get forward slash HTTP.
We tell them we want the DEF CON host and it's going to send back
okay with all these other HTTP headers and then it's going to
send us back to HTML. So we can take a look at the underlying
protocol by just looking at the ports that it goes over, right,
based on just the port on the server that is for HTTP, right?
So it's nice to inspect. And then if you think about it, like
this is the image of the matrix, right? It's kind of true, right?
Like everything is just streams that are flowing all the time
back and forth, right? So at some point maybe this will be how
everything looks when you start looking at everything. So maybe
everyone is over there, most likely. So what is BlueCat,
right? So what is the point of this, right? So there are three
main things that I've been able to kind of come up with reasons
why. You have a debugging tool for Bluetooth applications. So if
you're writing a Bluetooth app, you can use it to debug your own
application. You can see what's going on. Like if you're
trying to debug, did you modify the service record properly so
that other devices can see that record, right? And then whatever
process is handling the socket on the other side, you don't
want to have like a full blown client ready, right? You might
just want to have like a makeshift client to see what is
going on. Or if you want to like do some sort of emulation or
testing with inputs that you wouldn't normally put into your
client application, right? So if you kind of want to fuzz your
own app, right, you can do that with this and it's not a big overhead,
right? You can use it as a device exploration tool, right? So other
people's devices, other people's services that are written, right? So
your phone's services, because there are tons of them. And they vary
on different types of phones. You have old phones with insecure
services, new phones with more sophisticated services, right? And
then you have varying manufacturers have their own services, right? So
you can look at how those services work and like send random data and
try to debug the protocol that's there, right? And then you can record
those services using scripts, right? So you can just like scan and
kind of do it in an nmap fashion, right? So kind of output. So I have a
format to output this into a CSV file. So you can kind of just
aggregate tons of information about Bluetooth devices, which is
interesting and I have some cool graphs later. So you can also use
it as a component in building other applications. So you can use
the, just like you'd use Netcat to prototype an application, you
can actually use BlueCat to do the same thing. You can actually use
Netcat to prototype an application and you don't have to care so much
about the Bluetooth layer, right? Because you're handling that kind of
while it's deployed and then your service runs as your own thing and
it just cares about like standard in and standard out. It doesn't
know that it's talking over the, you know, the RF. All right. So
simple inline replacement for a Netcat example, right? So we have
Netcat, some machine name and a port and that's going to connect to
some server listening with Netcat on port 123, right? And then you're
going to have a pipe going this way and it comes out that side, right? So that's like a
the main kind of demo of Netcat, right? So we can do the same thing with BlueCat. So we
listen on RF channel 4 and then we connect to this MAC address on RF channel 4 and it
establishes that same connection, right? And you can do the same thing. You can send music or
movies. The throughput is like 100K, so it's not too good. But it does work with music, right?
Maybe not flat. Okay. So we're going to go ahead and show you how we can do this. So we're going to
compare with Nmap. So Nmap is going to scan a bunch of stuff, which is very useful. Everyone knows
about that. So what's the equivalent for BlueCat, right? So we have kind of two things. We can scan
for device names, which is what I was doing earlier, scanning everyone's device names. And then
you have this kind of output. So here we have a time stamp, the device name, whether we're paired
with it, and then whether the session is encrypted. And then what's falling off there is like an output, the RS, the
RSID, the RSSI of the connection, right? All right. So you can go farther in depth, right? You can list
the services of each of those devices, right? So it lets you actually expect the stuff that's kind of
running on that device. So you can think about these the same way you think about an IP address and
ports, right? It's the same thing. You have a MAC address, IP, and then you have these channel numbers
or PSN numbers. And then you have a MAC address, IP, and then you have these channel numbers or PSN numbers.
And then you have these channel numbers or PSN numbers. So you have the MAC address, IP, and the
network address. And then you have the MAC address. So you have this SEM for the L2CAT protocol. And
those are outlayed on the right. So this thing returns the entire URL which says that we're going to talk
over the B2 L2CAT protocol on PSN 19 on that MAC. Right? So you can just copy and paste that right back into
Bluecat and connect to it. So I'll go over that in more detail. You can also brute force scan. So this takes a
So if we scan this thing, we need to scan RF channel, RF com channels first, we can
see we have a bunch of open channels, so even if they're not advertised in the service discovery,
we can still find them this way.
And then if we scan L2 cap channels, you can actually look at all the channels that are
open from every possible L2 cap channel.
So even if they're not valid, it will still try to see if that stack will allow it.
And this goes up to a very high number.
But I've never really seen anything over, you know, I don't know, like 100.
All right, great.
So for the past three days, I've been walking around with my bag, scanning all the Bluetooth
devices.
And these are all their names.
I put a nice word bubble thing, right?
So all this specific stuff is really tiny, but there are a lot of iPhones, MacBook Pros
and Blackberries.
Yeah.
Do you guys all see?
Who sees there?
Machine.
There's a machine on this thing.
Who got invited to this talk during the week?
Nobody?
Nobody's afraid to raise their hand?
What?
Oh, yeah.
I see the scoreboard.
That was fun.
You guys left your Bluetooth on.
Okay.
Who saw the scoreboard advertised for the Blue Cat talk?
Like one?
A couple?
Okay.
It was a short amount of time.
Okay.
So I got statistics on this, right?
So there are 92 unique names that I found, right?
And sometimes devices won't send names, they kind of lag, and then they disappear.
But you definitely get their MAC address.
So I found 126 unique MACs just broadcasting.
So there are tons of other ways to find device MACs.
But this is the blatant one.
I didn't even think it would work.
I was like, no one will leave their Bluetooth on, you know, less even discoverable, because
these are discoverable Bluetooth devices.
I thought I was going to find like two and then be at the hotel, like, you know, just
staying, not knowing.
So I sent these 126 MACs 13,000 pairing requests with an invite to my talk.
So that was funny.
The people clapping are the ones that were invited?
So the reason I could do that is because you can script Blue Cat.
That's the point, right?
So I could write a program, and that's a pain in the ass.
I could say that here.
So bash scripting just makes everything so easy.
You don't need to care so much.
So if your name's on here, you're going to be able to do it.
I think this is the coolest names out of all the names, just to prove to myself that
these were not hotel guests.
So maybe the DOD is staying here.
So let's talk about URI monkeys.
So this little URL that I was talking about before, it kind of says everything that we
want to know about the service.
So you can think about like HTTP and HTTPS as equivalent design, right?
All right.
So we pretty much have three that I care about in this program to use that may kind of make
sense.
And then the object is kind of pushing it to what this program kind of does.
So the BT SPP, the Bluetooth Serial Port Profile, which is also called RFCOM, makes the most
sense for this kind of NCAT replacement, right?
It's a serial port protocol.
It's meant to take stuff that used to run over serial ports and make them wireless.
So that one's easy.
L2CAP kind of is a little bit different.
You kind of just have fixed width buffers.
So you can achieve the same thing, but it's, you know, it's kind of exactly the same thing.
So it's kind of redundant.
And then you have an object exchange, which is when you send files back and forth.
So these three mockier things, if you have these in the URL string, then that's what
they'll correspond to.
All right.
And you kind of have this weird Bluetooth stack.
So see RFCOM, which is a BT SPP.
And then L2CAP.
So RFCOM sits on top of L2CAP.
And then you have stuff that's kind of completely out of the range of BlueCat, which is like
audio.
So that kind of stinks.
And then the other, LMP, I don't know what that is.
So you kind of have limited range on the stack of Bluetooth, right?
Let's go over these profiles a little bit more.
So the SPP profile is designed to emulate RS-232 serial ports.
It's a serial port protocol.
So it kind of has the same major difference.
Major attributes of TCP.
So you're expected to have in-order delivery of all your messages.
And if it's not delivered, you'd expect that it would retry or just, like, kill the connection.
Right?
So you kind of have some guarantees with it.
Right?
It only has about 30 ports.
Depending on the stack, this, like, varies what you can use.
And then if you think of ‑‑ if you know port map, right, with the old run NIS, right,
would advertise on port map, it kind of works the same way.
You can't really be guaranteed that you're going to have a port.
So you can ask for something and then if someone else is using it, it just says, no, I'll put
you on a higher port.
So it's kind of a drawback.
Which is why you kind of need the scanning to, like, look at what port it actually ends
up on.
Right?
But it's the same consistently on a device.
So if you run BlueCat on a device and you get channel 4, it will probably always be
channel 4 unless you, like, you know, reflash the device, put some other services on it.
Okay.
L2 caps underneath RF com.
So you can make ‑‑ you can make it unreliable to UDP, but that's not really in the interest
of this stuff.
And then it has the default maximum packet size of 672 bytes, so you can kind of send
them over in chunks.
And then RF com sits on top of L2 cap.
So there's a PSM or a channel number 3 in L2 cap, which is kind of RF com runs over
all that.
And it has way more port numbers.
So I scan up to 65,000, and then somewhere people advertise it's like 40,000, and it's
all like the odd numbers.
Which is weird that you just have odd port numbers, but it's a great protocol.
Okay.
So here's a list out.
So you have TCP, UDP.
We all know those.
RF com.
We have 1 to 30.
We call those channels.
L2 cap.
We call it a PSM or a protocol service multiplexer.
And then the odd numbered.
So you have, like, a reserved at the base.
So these are the interesting ones, for the most part.
And that's 4,000 of them, and then the spec says it goes up to 32.
So.
It's kind of the lay of the land there.
So you can, just a side note, you can look up MAC addresses the same way you would look
up IP MAC addresses on network adapters.
So that's kind of, it gives you more information.
But nothing really aligns properly.
Like it doesn't say Apple incorporated like it would with the network MAC.
So it doesn't really tell you a lot of information.
All right.
So getting back to Bluetooth a little bit more.
We can use the dash E option, which is like from NCAT.
So here's an example.
So we have two actors in this.
We have the green and the blue.
All right.
So we're launching BlueCat with verbose dash V, which gives us this pound comment line.
Dash L for listen.
And it's going to choose any channel.
And then we're going to do dash E for bin bash.
So upon connection, I want to execute bin bash.
And set up standard in and standard out to be wired right there.
So.
We can then, after two, the blue computer will list the services on that first machine.
And it outputs that there's something listed on channel four.
So we can connect to that.
When we connect to that, I type hi.
And it shoves that command to bash and bash that out.
You know, there's a program in hi.
So that's kind of a cool usage.
You can kind of have a point to point remote access to some device.
Which is kind of cool if you like hang a Raspberry Pi in the corner.
And then you can just connect to it without a wire.
So I'm going to get a little more in depth on the Bluetooth plumbing.
Right?
How this kind of stuff can kind of be put together.
So we have this basic Bluetooth connection at the top.
Blue cat.
We connect to some URL, which is identifying the second blue cat process running somewhere else.
And they're going to exchange the standard in and standard out like you normally would.
So on the left, we have a terminal.
And on the right, we do the dash E option.
So it's just going to pipe the standard out from the terminal to the standard in in bin bash.
So you kind of remember that.
Remote control service.
Over Bluetooth.
This works the other way.
I just tested it.
So you can do a dash E on this side.
And you can have one process connect and then launch a service immediately when it connects to the server.
And on the other side, it connects to the same process.
Or a different process.
So you can have two processes talk to each other over a Bluetooth link.
And they never have to know anything about Bluetooth.
All right.
So I'm going to go through a bunch of devices.
So we just kind of like, you know, give a brief overview of how they would work.
Bluetooth has profiles.
So when we kind of look at this stuff, you can see profiles in these certain types of devices.
So we're looking from a specific angle with Blue Cat.
But that's not really the way that devices want to look at each other.
They want to look at each other and say, you're a phone, so you must have these, you must have a hands-free mode.
Right?
And then you can identify those with UUIDs and device classes.
So a device class will say, I'm a, you know, a laptop.
So I'm going to have laptop-like services that you can see if I have a device.
And then go forward with that.
So it's really crazy the way that they look up each other.
But underneath, if you just look at it from a raw implementation point of view, we have RF com and L2 cap channels or PSMs that you can connect to for these services.
And like in the case of like an audio gateway, sorry, it will go to another service that has like voice.
So it's kind of a collection of services on Bluetooth that compose a profile.
So if we start looking at something like a printer.
So we scan this thing, we get a Mac, and it's an OfficeJet 6300.
And we can see that it has a micro link nicking it on the Bluetooth.
So that doesn't tell us anything.
So unless you know that micro link sells to HP, then you can tell us it's HP or something, right?
But they probably don't exclusively.
So it's hard to really gain information that way.
But we can look at the services that are listed here.
So we obviously know it's a printer because we can just read the name.
And the device class will say I'm a printer.
And we can see that it has a serial port listed here, right?
So it's on channel 1.
So we can just try to connect to that with BlueCat and type some stuff and see what kind of error it gives us.
Bluetooth really isn't good for giving errors.
When people implement Bluetooth services, they just don't respond instead of give like an error message.
So it's a little bit tougher.
So we can type BlueCat-URL and just put that URL in there with the Mac and the channel number.
And connect directly to this thing.
And it turns out this printer, so BlueCat launches and it doesn't ask for authentication.
It's usually the other side.
So you would connect to this printer and the printer would be like, all right, that's fine.
I don't need to pair with you.
And it will just let you connect to this socket and print out.
That's not the case with a lot of devices.
But printers, completely anonymous access, right?
So.
So I messed with people with this first.
I found out when like a bunch of stationary was used.
And people were kind of mad.
So let's look at the next phone.
So this is Alcatel, right?
So let's take a look at BlueCat.
It gives us the device name, some audio gateway, object exchange, dial-up networking, right?
So we can use it as a modem.
And then we just have a serial port.
So if we just connect to the serial port.
This wasn't as easy as this.
But you can connect to it.
So I had to pair with this phone, right?
So we're pretty safe unless we pair.
But I guess there are pairing flaws that people have been telling me for the last couple of days.
So we can just type the AT Hayes connection or the commands to this thing.
And we can get the device manufacturer, the model.
So those are all easy.
Or you can just look at it from the name.
And we get the third one.
It's because there's a date that it's talking to me.
And at this point, I could have put more in.
But the guy that I was playing with this phone.
He cut off his phone once he started it.
Once I got excited, I was like, these commands are working.
This is awesome.
This is hard to find phones that you can actually do this to.
Because this was a really old phone.
New phones aren't friendly to people who want to just poke around on them.
Probably for a good reason.
All right.
So we can look at anything that's Bluetooth.
So if you look at a Wiimote, we see that it's service record is kind of weird.
So it returns these records, but they're empty.
It doesn't say any information.
So maybe it's trying to hide those things.
But we can see up there that we have three services listed.
And one's obvious.
I think it's the channel 11 or PSM 11.
And when we scan it, we actually find that it's 1, 11, and 13.
So 1 is kind of a default one.
So 11 and 13 are the ones we can talk this thing on.
But people have kind of completely reverse engineered the Wiimote stuff.
But if you were starting from scratch, you could do it like this.
And then kind of start sending stuff to those ports.
All right.
So we can take a look at the Nexus 4.
All right.
So we list the services on this.
And we see we have a headset gateway.
No serial port protocol, so we can't have fun with it.
No dial-up modem, so we can't mess with that either.
So the fun ones to look at are these BT SPPs.
They're usually text-based, ASCII-based.
Except for an example I'll show in a minute.
So we can try to connect to one of those.
So let's do the hands-free one.
It's the only one I could really find anything to look at.
So if you kind of Google that in, you can find profiles.
And the profiles will tell you kind of what some sort of established protocol for it is.
But the documentation is pretty bad and not uniform across all the manufacturers.
So I got this thing.
I kind of connected to it.
And the first thing I type now when I connect to the serial port protocol is I type AT or AT plus.
And have it give me an error.
And then if you say something really weird like AT star, it will just kick you off.
So to get it to give me an error is a first sign that there's somebody on the other side listening.
That we can try to, there's some commands that must do something.
So after reading this, reading all the profile stuff, we can see that the hands-free profile has a lot of AT commands.
Like the one that's the coolest one is dials a number.
So you can, this actually works on the Nexus 4.
You can do ATD and then like 55555, whatever.
Or I don't know, maybe an expensive phone number.
And it will, you'll call it, right?
So you can also like list the number and then list all the services that are there.
So there is a way to talk to these things.
They're just obscure and they don't really advertise all the stuff, right?
So it's a little bit difficult to kind of get information from these things.
So a thing that I did with Alex Whitmore like an hour ago, two hours ago was look at the YAP.
So I didn't know what it was.
I thought it was access point.
That's like kind of intuitively how I thought it was.
And I guess it's the iPod accessory.
So I don't like iPhones.
So the goal is like how can you stop, play stop start and control the auto tracks on the phone, right?
Like that would be pretty cool if you can disconnect from your computer or like write a full fledged app.
It was all software based.
It would interact with this.
And it turns out that there's a chance that it could be the same interaction as the standard UART in the Apple connector.
So if you just wired up into that.
So that's the kind of the hypothesis.
And it turns out so that they're the regular way you do this over the hard wire, right?
This is the same packet thing for saying I want you to play, right?
I want you to stop.
So that's like well documented for the hard line stuff.
But sadly it turns out that Apple has like a weird authentication coprocessor that's required to attach to this process.
So that makes it different than the actual wire line which makes it kind of undoable with BlueCat.
Unless we can kind of process this stuff fast enough.
But more research will be needed for this stuff.
All right.
So the next section is rapid prototyping with BlueCat.
So if you just want to make something really quick with bash scripts, right?
So how to prototype.
So this presentation was supposed to be given with a Bluetooth presenter.
So you know from an app, we press a button, first piece is just with a atravteam.
That the only thing on the phone would be an app that just sends characters over a socket, right?
So I press a button it just sends a B or an F.
Right?
Then on a laptop there's something that's listening it goes like into a script that's dispatching
all the characters as they come in and will respectively press back or forward to move my slides.
So that's the basis of it so we can go over how this, how this works.
it's a few lines. So we launch blue cat, we do a keep alive, verbose, to connect to this URL,
which is my phone on channel 4, and then when we receive a connection, we just throw it to
dispatcher.sh, which simply looks like this. So we just well read input. If the input's an F,
I go forward and then press the key for forward. So it did work great all weekend. So you can do
other stuff. You can say on any input, you can filter on different words and have it do
anything. So it's kind of like the sky's the limit with anything you want to control on this
device. So that's kind of the basic way of prototyping. So any way you can think of in the
future to kind of use that stream in that kind of same concept.
It's pretty easy to do. So I scanned for like over the course of three months from the same
desktop next to a computer lab. Every five minutes. And every single Bluetooth device that
was at the visible, I captured and stored and then wanted to run data analysis on it later. So
specifically, you know, I happen to write blue cat so it opens in a CSV format so we just end up
having tons of CSV files and we can just import those in a database. Or an R, which I did, and
that's some stuff. So kind of a shout out to R. It's awesome. So we can just read this file and
then filter based on the date. So convert them all to dates. And then make a histogram based on
dates and break them all up by into 100 bins. Right? So we get this thing. So this is February
to April. We can see this should be numbers, but I didn't go back and regenerate this thing. So
this is in the upward direction. So this is in the upward direction. So this is in the upward
direction. So this is in the upward direction. So this is in the upward direction. So this is in the
it's pretty high. This is like 2,000 scans, the magnitude of this stuff. So you can see this
dip. So why is there a dip around March 23rd? So you can say why are people not walking around
here? So we can take a look, filter more just in between those date ranges for the month of March,
right? We can see that it's really close around the 21st to the 25th. All right. So I was like,
why did my script fail or something that was running and
then I looked and it's spring vacation. It's like towards the
end of spring vacation. So it kind of made sense you can align
some data collection with the fact that students were not
coming to school. So this was at the university. All right. And
then so the more scary piece is I can look at just me. So this
is when I was in my office. Right? So I can do that for
anybody and you kind of know their name because it's their
MacBook or their phone. Right? Like so and so's iPhone. Right?
So this is I guess I'm a slacker in March especially. So now we
can get into the kind of architecture and design of
Blue Cat. So one awesome piece of it is it runs on I've only
really tested on Mac and Linux but the Blue Cove library in
which it sits runs on tons of different platforms like Symbian
Android and Windows if you want to use that. So it works on
Blues great. So this is like the main advantage over using a
different library like there's like Pi Blues but then you're
stuck with Blues and you can't really use it on an I on a Mac
which I mean or anything in the future. It doesn't have this
good abstraction layer because you're stuck in the Blues
libraries. All right. So it's pretty small. It's pretty
small. I mean there are like a bunch of Java files. It's Java
based so you can do appropriately but I like Java. So and then it
kind of gets offloaded to a series of different Java files
that contain native libraries for whatever platform you're on.
Right? So the business logic right is all contained in the
Java stuff and then we just call based on the different
platforms, different libraries and kind of arrange everything
appropriately. So there's one main file and it will run on
like Armlet. And then there's one main file and it will run on
Linux, Mac 64 bit, Linux 32 bit, 64 bit, Ubuntu, Fedora, all that
stuff. All right. So here's one kind of diagram of how this stuff
kind of will interact with everything. So you run BlueCat.
It sits on top of BlueCove. It makes all those calls. And then
if it's Mac, it just offloads it straight to the Apple API or it
outputs everything to Blues if Blues is available which will hit
the Linux, you know, Bluetooth D and the kernel. And then it
works fine. And then whatever Linux is running on that
implemented Blues, it will work fine on. Right? And then that
will actually hit the actual hardware. So it's very
versatile, which is the design. So like a lot of people can use
it. All right. So this is an eye chart. It's just a BlueCove
stack, the way it interacts with everything. I don't really want
to go over it too much. But I want to talk about how the JNI
libraries work. All right. So I want to talk about how the JNI
libraries work. BlueCove specifically offloads stuff
using JNI libraries. So who's heard of JNI libraries before?
All right. So I think they're pretty awesome because you can
do all the business logic in Java and then ‑‑ sorry. Oh, no.
Okay. So first of all, what the fuck is that on the screen? Holy
shit. Lots of people want to talk about lots of things. We're
not going to let them talk about it. We're not going to let
that happen. Yeah. Oh, my God, is that boring. Oh, it has a
Bluetooth controller on it. Never mind. That's cool. All
right. You all know the drill. Holy shit. All right. Get up
here, man. Hey, wait a second. Were you just in the last track we
were in? Is this the last track we were in? Yeah. All right. All
right. Here I am. Assumption I'm probably the final person in Sugar
City. That's not fair. This is the last start but that's how
people get along. He won't do it here. He's trying to make me
wrong. Okay. So you're doing a class here, right? And we've got
Jesus, don't you pay attention? I can just take the bottle. Okay. Slow down, champ.
And what? You're going for a second one already? All right, everybody. You know the drill.
Welcome to DEF CON. We'll see you soon. He's going to go back to the
slide now. Waffles got off the stage. What's the timing? Okay. Okay. Right on time. All
right. So we have all this stuff with JNI. And the way that that gets set up to actually run all
these platforms, it's really just a script. So it's kind of like a dispatching script. So we
just kind of weakly match the, you know, the, you know, the, you know, the, you know, the
OS type, if it's Darwin, Linux, architecture, and spit it out. So if you want to use BlueCat and
it's not supported on the architecture, I can just build all these libraries on your
architecture and wire it in if you want to use it. Right? Okay. So send me an e-mail if that is
the case. All right. And then we simply attach the libraries and then run this main driver for
the stuff. And then one problem, so if you look at this file and you're like, why is he
filtering out the standard error? I don't know. I don't know. I don't know. I don't know. I
don't know. I don't know. It's because some stacks output tons of debugging information to
spit it out and there's no way to shut it off. So I just filter it in some NS auto-release no
pull on a Mac. It's a spam thing. So this just fixes that. Cool. So how does JNI work inside
the libraries? All right. So somewhere in this BlueCode program, when it runs the text EOS that
it's running on and then loads the specific native libraries for it, it's going to search
everything in the load library path, which is in default inside the jar file, to find whatever
stack that it should be running on. All right. So once that's loaded up, it then has these extra
native functions and they're ready to call. All right. So you make a call to this, RF server get
channel ID impl. All right. So this is something, it's a pretty low level thing. You have to get
the handle for the specific connection. And that gets offloaded to the C code, or it would be
whatever C++ code they want to use in the native library, which is declared like this with like a
JNI header to actually interact with that specific stack that you're running on. Right? So you'll
have to do this on every platform that it runs on. So I didn't do this. This is all the BlueCode
people, which I don't have. Their logo is on a different page. So they've done tons of work and
it seems like they all work for big companies anyway, so they're probably getting paid. So that's
good. And thanks.
Any questions?