It'd be an analog to ethernet's promiscuous mode, where all frames received
are passed up the stack, instead of just the frames matching the devices MAC
addresses.
Is there such a thing available in BlueZ?
-A.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Andrew Kohlsmith wrote:
> On Monday 04 December 2006 09:07, Marcel Holtmann wrote:
>> The radio, baseband and link manager are part of the Bluetooth chip and
>> not accessible via the host operating system.
>
> That's what I was getting at; the device *does* see all communications, but
> unless there is a method to flip on the equivalent of ethernet's promiscuous
> mode, you'll never see anything not intended for you. Your message suggests
> that there is no HCI call to do this, which puts me out of luck.
No. Your assumptions are wrong. The device does *not* see all
communication, even with complete control of the baseband firmware,
putting a mass produced standard device into promiscuous mode is
impossible.
Your analogy between Ethernet and Bluetooth is flawed. Ethernet packets
are transmitted on a wire. Wires are quiet between packets. The signal
to noise ratio is good. This allows a device easily to identify the
start of any packet without knowing anything about the contents.
Bluetooth packets are transmitted on a radio. The signals you're looking
for are often not far off the noise level. This means you get random
data between packets. To avoid triggering on the noise you need to look
for a long sequence of bits. To reduce wastage, the sequence used is
related to part of the MAC address of the master. So, the only (easy)
way to know that the packet exists at all is to know the address being
used.
However, before you get that far, there's the problem of knowing which
channel to listen to. Bluetooth packets are spread over 79 frequencies.
The link hops between these, changing frequency for every packet. A
(standard) radio can be tuned to only one frequency at a time. So, in
your Ethernet analogy, imaging your Ethernet packets are coming down
79 wires in an almost random order. You have no custom hardware so you'd
have to switch those wires in and out of your Ethernet card in the right
order before each packet is received.
This is a very important point. You wrote that "any device in a shared
medium would by its very nature have to receive all messages". At best
an unsynchronised Bluetooth device gets just one seventh-nineth of all
messages into its radio and then has to worry about distinguishing
messages from noise.
Supposing you solve the frequency hopping problem - say by having an
array of 79 devices, one for each frequency - and the correlator
problem, you next have to contend with whitening. Each packet is
trivially scrambled to remove DC bias. The scrambling is simply related
to the Bluetooth clock, so can take one of 64 sequences. Bluetooth chips
are set up to know the sequence to use for each packet. They can't
simply try all of them.
Then, there are persistent changes to the state of a link. For example,
switching between basic rate and enhanced data rate changes the packet
format. A Bluetooth receiver has to know which mode to be in. It knows
because it was party to the LMP negotiation. A stateless promiscuous
sniffer would have to try both.
This gets you as far as knowing that a packet exists. In theory, all
the problems so far could be overcome with sufficient custom equipment,
but you're probably talking about a crate of FPGAs.
However, even if you were to assemble all that equipment, you will
fall over at the next hurdle: all non-trivial Bluetooth traffic is
encrypted specifically to prevent sniffing. Unless you know the
encryption keys for all traffic in the area you want to sniff, you're
doomed (this applies to normal Bluetooth sniffers to - you have to
get the encryption keys into them somehow).
The best you could do with a standard dongle, albeit with modified
firmware, is to report all the unencrypted traffic in a single
piconet. However, that's a lot less than a promiscuous mode.
Man in the middle attacks are different. In this case, the man in
the middle wants to intercept the traffic for just one connection.
This is much closer to the sniffer problem and doesn't require being
promiscuous. It would still require firmware modification.
- Steven
--
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Andrew,
> That's what I was getting at; the device *does* see all communications, but
> unless there is a method to flip on the equivalent of ethernet's promiscuous
> mode, you'll never see anything not intended for you. Your message suggests
> that there is no HCI call to do this, which puts me out of luck.
>
> Have you seen or heard of anyone using two BT devices in a Linux box to
> achieve a "man-in-the-middle" type of monitoring system?
What you're looking for is a Bluetooth Sniffer. Such devices are
commercial available and you special low level firmware (never disclosed).
However, your assumption is wrong that the device sees all traffic and
simply throw away everthing it is not interested in.
To sniff a Bluetooth connection you need the hopping sequence of the
master. Unless you don't have this it is impossible to know which channel
is used by any two devices to communicate in a given time slot. Not to
mention encryption....
So even with a bluetooth sniffer you first need to synchronize to the
master of a bluetooth connection before you can extract anything useful.
Normaly this is done by connecting from the master to the sniffer as a
slave.
Ciao,
Peter
| Peter Wippich Voice: +49 30 46776411 |
| G&W Instruments GmbH fax: +49 30 46776419 |
| Gustav-Meyer-Allee 25, Geb. 12 Email: [email protected] |
| D-13355 Berlin / Germany |
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Monday 04 December 2006 09:07, Marcel Holtmann wrote:
> if you don't believe me, then feel free to check the specification. A
> Bluetooth device is not actively participating in any communication
> unless you create a piconet. If no piconet exists, then it only scans
> for inquiry and page beacons.
I wasn't disbelieving, at least not on that kind of level.
> The radio, baseband and link manager are part of the Bluetooth chip and
> not accessible via the host operating system.
That's what I was getting at; the device *does* see all communications, but
unless there is a method to flip on the equivalent of ethernet's promiscuous
mode, you'll never see anything not intended for you. Your message suggests
that there is no HCI call to do this, which puts me out of luck.
Have you seen or heard of anyone using two BT devices in a Linux box to
achieve a "man-in-the-middle" type of monitoring system?
-A.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Andrew,
> > a Bluetooth chip doesn't receive any packets that are not meant for it.
> > You must understand that Bluetooth works totally different than for
> > example Ethernet or Wireless LAN.
>
> With all due respect, that simply cannot be true. Any device in a shared
> medium would by its very nature have to receive all messages in order to
> determine whether a message was intended for it.
if you don't believe me, then feel free to check the specification. A
Bluetooth device is not actively participating in any communication
unless you create a piconet. If no piconet exists, then it only scans
for inquiry and page beacons.
This means that even if another piconet has been established right next
to it, your passive device will ignore it. All chips are designed this
way and unless you implement your own baseband, you don't see any of
these beacons at all.
The radio, baseband and link manager are part of the Bluetooth chip and
not accessible via the host operating system.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sunday 03 December 2006 08:32, Marcel Holtmann wrote:
> a Bluetooth chip doesn't receive any packets that are not meant for it.
> You must understand that Bluetooth works totally different than for
> example Ethernet or Wireless LAN.
With all due respect, that simply cannot be true. Any device in a shared
medium would by its very nature have to receive all messages in order to
determine whether a message was intended for it.
Ethernet compares the received frame's recipient MAC address to its own.
Wifi's similar. CAN and I2C do the same. Hell, plain old ModBus does this
over RS485, albeit in software. If BT doesn't have a standard command to do
this that's fine, and actually may have been intentionally removed as some
kind of security measure. It seems unlikely that it's impossible, though,
and much like cellular phones, the method probably exists, but needs to be
reverse-engineered.
That's a shame, since it'd make monitoring BT communications so much
easier. :-)
Has anyone experimented with a box with two BT devices in it in order to
perform the equivalent man-in-the-middle type of monitoring?
-A.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Andrew,
> It'd be an analog to ethernet's promiscuous mode, where all frames received
> are passed up the stack, instead of just the frames matching the devices MAC
> addresses.
a Bluetooth chip doesn't receive any packets that are not meant for it.
You must understand that Bluetooth works totally different than for
example Ethernet or Wireless LAN.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel