Tip:
Highlight text to annotate it
X
So anyway, it's my pleasure to turn the screen and mic over to this gentleman for his talk
on netcat for Bluetooth. Just go? >> JOSEPH PAUL COHEN: Hopefully the presentation
remote will work and it doesn't. It was Bluetooth. So I'll tell you how it was made and how it
doesn't work now for some reason. One more chance. I'm here to talk about Blucat. Who's
heard about Blucat so far? Awesome. I'm Joseph Paul Cohen. I'm a Ph.D. student at U Mass
Boston. I do a side thing basically a Cybersecurity computer science education.
Do a lot of machine learning and computer vision stuff so it's kind of dual tracks,
right? So this is the fun stuff. So I want to just have some questions to gauge
the audience, right? So how many of you guys have used Bluetooth API whether it's blues,
OSX or Windows or whatever? Okay. Who's used netcat to talk to a web server?
All right. So that's half. Okay. Who's created an outrageously complex script to do some
task? Okay. So these are kind of all going to come together in this talk. It seems like
everyone is well‑versed. The overview of sessions of this we're going to talk about
streams and how they're awesome and fundamental and how Blucat ‑‑ how you can replace
Blucat in line with wherever you use netcat. Any situation you can think about using netcat
over an IP address, with Blucat you replace the IP addresses with Macs and then you just
have to be in range. And we also have Blucat as Bluetooth and map so we do scanning and
service discovery functions. And then basically, I wanted to talk about
RF com and zoom cat. Those are understood by Blucat because they make sense. You have
port numbers and you can talk to them directly. And then we're going to look at some devices
like Blucat and see how you examine other devices with Blucat. How to prototype and
stats and then if we have time, the architecture of how Blucat works on tons of architectures,
right? So first, streams are awesome. So I hope everyone agrees. You can take something
like a file and you can turn it into stream and you can pipe it into VLC and abstract
everything that has to do with a computer to a stream.
So once it becomes a stream, really don't care where it goes.
But you know, we use streams every day when we talk to pal talk. So every time you go
on. Okay. Well, Blucat 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. Anyway, you have a computer. And it turns
into a stream and you can turn it into pal talk and back, right? So that's how that kind
of communication works 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. Inside this block,
right? The computer just talks to this thing and at the other side it's going to come out
to pal talk and from that side, the responses go into this ‑‑ you know, blob and come
out the other side to you. And you don't really have to care what's inside there. It gets
abstracted with all the layers. So the Internet would work. Send some stream. It goes through
a series of tubes and comes out the other side and you don't really care. So you take
a 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 abstract really complicated things
and just kind of ignore that they exist no matter how dysfunctional they are.
So it to really appreciate the usage of just talking to these services, right, we can take
a look at HTTP. So just want to go over this simple, make sure everyone's on the same page.
HTTP is awesome. Simple, human readable. You can know what's going on by reading traces.
Debugging is easy, you can look right at it in any kind of debugger and you don't have
to read the spec, you can see all this stuff. You can add custom stuff so it's not really
so picky. You know, with what inputs and outputs it does. So it's very forgiving. 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 you can think of it as a tiny text file. 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 string get and you get back whatever response.
So here's one for DEF CON so we do get/HTTP tell it we want the DEF CON host and it's
going to say okay with all the other headers and send us back the HTML. We can look at
the underlying protocol but look at the ports it goes under based on the port on the server
that is for HTTP, right? So that's nice to inspect. And then if you
think about it, the image of the matrix is true. Everything is just streams flowing back
and forth all the time. So at some point maybe this will be how everything looks when you
start looking at everything. So maybe everyone is right there, most likely.
So what is Blucat? So what is the point of this? So there are three main things I've
been able to come up with reasons why. 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 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 a full blown client ready. You might just want to have
a makeshift client to see what is going on or if you want to do some sort of emulation
or testing with inputs that you wouldn't normally put into your client application, so, if you
kind of want to fuzz your own app, you can do that with this and it's not a big overhead.
You can use it as a device exploration tool. So other people's devices, other people's
services that are written. 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 sophisticated services and different manufacturers have different services.
You can look at how those work and send random data and try to debug the protocol. You can
just scan and kind of do it in n map fashion. So kind of I have a format I'll put this to
a CSV file so you can aggregate tons of information about Bluetooth devices which is interesting
and I have 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 Blucat to prototype an application and you don't have to care so
much about the Bluetooth layer because you're handling that while it's deployed and your
service runs as its own thing and runs in as standard in and standard out. Doesn't know
that it's talking about RF. So simple in‑line replacement for a netcat
example. So we have netcat. Machine name and a port and that's going to connect to some
server. List in with netcat on part 123 and you can have a pipe going this way and it
comes out that side. So that's like the main kind of demo of netcat. Right? So we can do
the same thing with Blucat. We listen on RF channel 4 and then we connect to this Mac
address on RF channel 4 and it establishes that same connection and you can do the same
thing. You can send music or movies. Throughput is like 100k so it's not too good.
But it doesn't work with music, right? Maybe not flak. So we can 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 Blucat, right? We have two things. We can scan for device
names which is what I was doing earlier, scanning everybody's advice names and have output.
So we have time stamp. Device name and whether we're paired with it and whether the session
is encrypted and whether what's fallen out is the RSSI of the connection, right?
All right. So you can go farther in depth. You can list the services of each of those
devices, right? Let you actually expect the stuff that's run on that device. You can think
about these the same way you think about an IP address and ports. Same thing. You have
a MAC address, IP, and then you have these channel numbers or PSMs for the L2 cat protocol.
And those are outlaid on the right. This thing returns the entire URL which says we're going
to talk over the B2L2 cat protocol on PSM19 on nmap. You can paste that and go right to
it. I'll go to that in detail. You can brute force scan. This takes a long time the way
I've done it. So maybe it's faster with a little other implementations but this is a
cross platform version. So we scan this thing, we scan RFcom channels first, we have bunch
of open channels even if they're not advertised in service discovery we can find them this
way. If we scan L works cat channels you can look at all the channels open from every possible
L2 cap channel so even if they're not valid it will still try to see if the stack will
allow it. This goes up to a high number and I've never really seen anything over ‑‑ I
don't know, like 100. So for the past three days I've been walking around with my bag
scanning all the Bluetooth devices, these are all names. I put a nice word name bubble.
All this specific stuff is tiny but they're all iPhones, Mac Book Pros and BlackBerries.
Did you guys all see ‑‑ who sees their machine on this thing? Who got invited to
this talk during the week? (Laughter)
Everybody's afraid to raise their hand? Scoreboard. That was fun. Left your Bluetooth on. Who
saw the scoreboard advertised for the Bluetooth talk? One? Short amount of time. I got statistics
on this. So there are 92 unique names I found. And sometimes devices won't send names. They
kind of lag and then they disappear. But you definitely get their MAC address. I found
126 unique MACs. There are ways to find device MACs. This is blatant. No one would leave
their Bluetooth on, these are discoverable Bluetooth devices. I thought I'd find two
and they'd be at the hotel, just staying, not knowing. So I sent these 126MACs, 13,000
pairing requests with an invite to my talk. So that was funny. People clapping were the
ones invited? Okay. So the reason I could do that is you can script Blucat. This is
the point. I can write a program and that's a pain in the ***. Bash script makes everything
easy. You don't have to care so much. If your name is on here, I think these are the coolest
names out of all the names. Just to prove to myself these are not hotel guests so maybe
the DoD. So let's talk about URI molecules. This little URL I said before, it tells you
about what you know about the service. HTTP and HTTPS is equivalent design. We have three
I care about in this program to use that kind of make sense and then the object is kind
of pushing it to what this program kind of does. So the BTP, Bluetooth serial port profile
which is also called RFcom makes the most sense for this Ncat replacement. Serial port
protocol, take stuff that used to work over serial ports and make them wireless. That
is easy. L2 cap is different. You have fixed width buffers that you send over, you negotiate
like a size. So you can achieve the same thing. But it's ‑‑ you know, redundant. Object
exchange is when you send files back and forth. So these three 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 RFcom sits on top of L2 cap and then you have stuff that's out of
range of Blucat which is audio, so that kind of stinks. And then the other ‑‑ I don't
know what that is. You have limited range on a stack of Bluetooth. Let's go over these
profiles a little bit more. So the SPP profile is designed to emulate
RS232 serial ports. A serial port protocol. So it has the same major attributes of TCP.
So you're expected to have in order delivery of all your messages and if it's not delivered
you would expect it to retry or kill the connection. So you have guarantees. And it only has about
30 ports. Depending on the stack, this varies what you can use and if you know port map,
with will old run NIS advertised on port map, it runs the same way. You can't be guaranteed
you can have a port. You can ask for something and if someone else is using it, it 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 look at what port it actually ends up on. It's the same consistently on
a device. If you run N cat and you get channel 4 it will probably always be channel 4. Unless
you reflash the device, put other services on it. You can make it unreliable to UDP but
that's not really in the interest of this stuff.
And then it has a default maximum packet size of 672 bytes so you can send them over in
chunks. RF com sits on top. There's channel 3 in L2 cap which is 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 40,000 and it's all, like, the odd numbers which is weird that you just have
odd port numbers. But it's weird protocol. So here's a list now. So you have TCP/UDP.
We all know those. RF com. L2 chap PSM, and then the odd numbered so you have reserved
at the base. So these are the interesting ones. And that's 4,000 of them 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 look up
IP addresses. 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 network Mac
so it doesn't tell you a lot of information. All right of
So getting back to Bluetooth, we can use the ‑‑ e option which is from N cat. So we
have two actors, green and blue. We're launching Blucat with dash L for listen and it's going
to choose any channel and bin bash. I want to execute bin bash and set up standard in
and standard out. Going to be wired right there. So we could then blue computer will
list the services on that first machine. It outputs that there's something to listen to
on channel 4. We connect to that. It's show that command to bash and bash is a program
in high. So that's kind of a cool use. You can have a point to point remote access to
some device, which is kind of cool if you hang a Raspberry Pi in the corner and connect
to it without a wire. I'm going to get more in depth with Bluetooth plumbing and how this
can be put together. So we have basic Bluetooth connect at the top. Netcat. Identify a second
URL and they're going to exchange a standard in and standard out like you normally would.
On the left we have a terminal and on the right we did dash E option so it's going to
pipe the standard out from the terminal to the standard in in bin bash. So you kind of
have remote control service over Bluetooth. All right? This works the over day. I just
tested it ‑‑ other way. You can have one process connect and launch a service immediately
when it connects to the server and on the other side it connects to a different process
so you can have two processes talk each other over a Bluetooth link and they never have
to know anything about Bluetooth. I'm going to go through a bunch of devices give a brief
overview of how they work. Bluetooth has profiles when we look at this stuff, you can see profiles
in these certain types of devices. So we're looking at a specific angle with Blucat. But
that's not the way devices want to look at each other, they want to look at each other
and say you're a phone so you must have a hands free mode. You can look at device classes,
it will say I'm a laptop so I'm going to have laptop like services that you can see if I
have and then go forward with that. So it's really crazy the way that they look up each
other. But underneath, if you look at it from the raw implementation point of view, we have
RF com and L2 channels or PSMs that you can connect to for these services. In the case
of an audio gateway, it will go to another service that has voice. It's kind of a collection
of services on Bluetooth that can pose a profile so, if we start looking at a printer, it's
a Mac Office 3200 and it has a microlink nick in it on the Bluetooth. That doesn't tell
us anything unless you know that micro link sells the HP and you can tell us it's HP but
they probably don't exclusively. So it's hard to gain information that way. But we can look
at the services listed here. We know it's a printer because we can just read the name
and device class will be ‑‑ will say I'm a printer. And we can see that it has a serial
port listed here, right? So it's on channel one. So we can just try to connect with that
with Blucat and type stuff and see what type of error it gives us, Bluetooth isn't good
forgiving errors, but when people implement Bluetooth services, they just don't respond
instead of give an error message, so it's tougher. Blucat ‑‑ URL and put that URL
in there with the Mac and channel number. And connect directly to this thing. It turns
out this printer ‑‑ Blucat launches, it doesn't ask for authentication. It's usually
the other side. So you'd connect to the printer and the printer would be like yeah, that's
all right. It's fine. I don't need to pair with you. Let you connect to the socket and
print out. That's not the case with a lot of devices but printer is completely anonymous
access, right? (Applause)
>> JOSEPH PAUL COHEN: I messed with people with this. I found out stationary was used
and people were mad. This is Alkatel. Gives us device name, dial up networking so we can
use it as a modem and 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 and it let's say ‑‑ so
I had to pair with this phone, right? We're pretty safe unless we pair. There are pairing
flaws people have been telling me the last couple days. So we type the AT Hayes commands
to these things, get device manager, model. Those are all easy. Or you can just look at
it from the name and we get the third one is because there's a date that it's talking
to me. And at this point, I could have put more in but the guy I was playing with his
phone, he shut off his phone once he started ‑‑ I'm like these commands are working,
this is awesome. It's hard to find phones you can do this to because it's a really old
phone. New phones aren't friendly for people who want to poke around on them. Probably
for good reason. We can look at anything that's Bluetooth. If we look at WIImote, service
records are empty, maybe it's trying to hide things but we can see up there that we have
three services listed. I think it's PSM11. When we scan it, we actually find it's 1,
11, and 13. So 1 is a default one. So 11 and 13 are the ones we can talk to this thing
on. People have completely reverse engineered the WIImote stuff. So we look at the nexus 4. So we list the services
on this and we see we have a headset gateway. No serial port protocol. So can't have fun
with it. No dial up modem so we can't mess with that either. Fund ones to look at are
BTPSPs, they're usually ASCII based except for an example I'll show in a minute. So we
can try to connect to one of those. Let's do the hands‑free one. The only one I can
find a way to look at. If you Google that in, you can find profiles and profiles will
tell you kind of what some sort of established protocol for it is. Documentation is pretty
bad and not uniform across all manufacturers. So I got this thing, I connected to it and
the first thing I type now when I connect to the serial port protocol is type AT or
AT+ and have it give me an error. If you say something weird AT star, it will kick you
off. To get an error is the first side there's somebody on the other side listening that
we can ‑‑ there's some commands that must do something. If they're reading all the profile
stuff, you can see it has a lot of AT commands like the one that's the coolest ones is dials
a number, you this works on Nexus4. Maybe on an expensive phone, and it will call it,
right? You can also list a number and list the services that are there. There's a way
to talk to these things. They're just obscure and don't really advertise all the stuff.
So it's difficult to kind of get information from these things. A thing that I did with
Alex Whitmore an hour or two ago was look at the YAP, I thought it was access point.
That's how I intuitively thought it was. It's the iPhone accessory protocol. I don't like
iPhones but ‑‑ so the goal is how can you play stop, start, control the auto tracks
on the phone, right? That would be cool if you could unplug from your computer or write
an app that would interact with us. It turns out there's a chance it could be the same
interaction as the standard UR in the Apple connector so, if you just wire up into that.
That's the hypothesis and it turns out so they're the regular way you do this over the
hard wire, this is the same packet thing for saying I want you to play, I want you to stop.
So that's like well‑documented for the hard line stuff. Sadly, it turns out Apple has
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 undoable with Blucat 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 Blucat. So, if you want to make something really quick with bash, right? So how to prototype.
So this presentation was supposed to be given with a Bluetooth presenter. That ‑‑ the
only thing on the phone would be an app that just sends characters over a socket. So I
press a button and it just sends a B or an F. And then on our laptop somebody is listening
and goes 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 works like a few lines. We launch Blucat. Do a keep alive, verbose
to stay on this URL on 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 is an F, I go forward and press the key for forward.
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. It's like the sky is the limit
with everything you want to control on they device. So that's kind of the basic way of
prototyping so anyway you can think in the future to use that stream in the same concept,
it's pretty easy to do. So I scanned for over the course of three months from the same desktop
next to a computer lab. Every 5 minutes and every single Bluetooth device that was visible.
I captured and stored and then wanted to run data analysis on it later. I happened to write
Blucat so it opens in the CSV format and we have tons of files and import those into a
database or in R which I did and analyzed stuff. So kind of a shout out to R, it's awesome.
Read this file. And then filter based on the date convert them to dates and make a histogram
based on dates and break them into 100 bins. So we get this thing February to April. And
we can see this should be numbers but I didn't go back and regenerate this thing. So this
is in the ‑‑ in the upwards this is high. 2,000 scans that the magnitude of the 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 teak a look filter more, just in between
those date ranges for the month of March, right? You can see it's really close around
the 21st to the 25th. So I was like why? Why did my script fail or something that was running?
And then I looked and it's spring vacation, it's towards the end of spring vacation. Made
sense you can align the data collection with the fact students were coming to school. This
was at a university. More scary I can look at just me. This is when I was in my office.
Right? So you can do that for anybody and you kind of know their name because it's their
Mac Book or their phone. So and so's iPhone, right? So this ‑‑ I guess I'm a slacker
in March especially. Now we can get into the architecture and design
of Blucat. One awesome piece is I only really tested on Mac and Linux. But the Blucove library
in which it sits runs on tons of platforms like Symbion and Android and Windows, if you
want to use that. Works on blue is great. There's high blues but then you're stuck blues.
And you can't really use it on an Mac which or anything in the future. You're stuck in
the blues libraries. Perfect so it's pretty small. I mean there are a bunch of Java files.
This is Java based. You can view appropriately. But I like Java.
And then it kind of gets offloaded to a series of files that contain native libraries for
whatever platform you're on, the business logic is all contained in the logic stuff
and we call based on the different platforms different libraries. And kind of arrange everything
appropriately. This is one main file and you can run on arm Linux, Mac 64 bit, Linux 32
bit, 64 bit, ubuntu, fedora, all this stuff. This is a diagram of how this interacts with
everything. You run Blucat. It sits on top of Blucove and makes all those calls and if
it's Mac it sits on Apple API or opens everything in blues if blues is available which will
hit Linux and Bluetooth D and kernel modules and whatever Linux is running on that implemented
blues, it will run fine on and that will actually hit the actual hardware. So it's very versatile
by design so a lot of people can use it This is an eye chart with the Blucove stack
the way it interacts with everything. I don't want to go over it too much. But I want to
talk about how the J and I libraries work. So Blucove specifically offloads stuff using
J and I libraries. Who's seen this before? You can do business logic in Java. Time ‑‑ oh,
no. (Applause.)
>> Okay, first of all. What the *** is that on the screen? Holy ***.
>> Lots of people want to talk about lots of things. We're not going to let that happen.
>> Oh, my God is that boring. Oh, it is a Bluetooth controller on it. Never mind, that's
cool. You all know the drill. Holy ***. Get up here, man. Wait a second. Weren't you just
in the last track you were in? >> Is his name Sarah? What's your name.
>> Thomas waffles. Atomic waffles. Thank you. Everybody, this is atomic waffles atomic waffles,
this is everybody. I'm lonely over here. >> I'm sure you are.
>> Where did you come from? >> That's atomic waffles. Jesus, don't you
pay attention. >> I can just take the bottle.
>> Slow down, champ. 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. Waffles just got off the stage.
Okay. We're on time.
>> JOSEPH PAUL COHEN: All right. So we offload this stuff to J and I and the way that that
gets set up to actually run on all these platforms really is a script. So it's like a dispatching
script so we just kind of weekly match the OS type and Linux architecture. And spit it
out. So, if you want to use Blucat and it's not supported on 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 we simply attach the libraries and 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 extended error, it's because some stacks output tons of debugging information
and send it out and there's no way to shut it off. So I just filter it and some NS auto
release on a Mac this just fixes that Cool. So how does J and I work inside the
libraries. So somewhere in this Blucove program when it runs detects the OS that it's running
on and 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. So you make a call to this. RF server, get
channel ID. So this is something pretty low level thing you have to get the handle for
this specific connection. That gets offloaded to the C code or whatever, C++ whatever they
want to use in the native library which is the like this with a J and I 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 Blucove people which
I don't have ‑‑ their logo is on a different page. They've done tons of work and it seems
like they're working for different companies anyway so they're all getting paid and that's
good. And thanks. (Applause.)
Any questions? I can take questions. No? Okay, thank you.
>> Any ‑‑ I found that as long as the dongle is supported by the OS it's supported
by this stuff. It calls the native ‑‑ all you need to know is their Mac. If you get
that through service discovery, you're good or hack RF or Uber dude, that's another way.
>> All right, everybody, questions? He's got stickers to hand out. He will answer questions,
they're going to be in the chillout cafe'. Hi.
>> I have stickers, anyone want Blucat stickers?