
DopplerFi – Communication Between BLE and Wi-Fi by Injecting Doppler Shifts - snaky
https://arxiv.org/abs/1811.10948
======
_Microft
Another ingenious method (ab)used WiFi to determine the distance (decimeter
level, i.e. sub-nanosecond absolute time-of-flight measurements!) from a
single accesspoint with common hardware.

This should be the paper, I think:
[https://www.usenix.org/system/files/conference/nsdi16/nsdi16...](https://www.usenix.org/system/files/conference/nsdi16/nsdi16-paper-
vasisht.pdf)

~~~
toomuchtodo
Isn’t this how tech companies (Google, Apple) are determining your location
indoors without GPS (database of computed locations of previously seen WiFi
access points)?

~~~
_Microft
They use WiFi but not like that. As far as I know even signal strength is
dropped as it fluctuates too much. They often use only presence or absence of
networks to tell between which 'known' locations the user is moving.

~~~
EGreg
Or beacons

------
molticrystal
It seems like their is prototype code for what is in the paper [1] if you want
to try it out, the warp board is ~$5k and I didn't look up how much the
ubertooth ran.

Fortunately some wifi chips can be used as SDR to transmit IQ data which
likely will be enough to run the experiment with some gnuradio modifications
and further development, namely BCM43xx related devices installed Samsung
Galaxy S2 & S4, Nexus 5,6 & 6p, Raspberry Pi 3, B3+ and Zero W, Huawei P9, &
soon hopefully the TP-Link Talon AD7200 [2]

Having inexpensive SDR IQ capabilities through with the ability to transmit
arbitrary signals (NEX_SDR_START_TRANSMISSION ioctl) in the wi-fi (ISM) bands
such as the 2.4/5 ghz and recently the 60ghz radio bands significantly lowers
the barrier of entry to people wanting to experiments like this. The 60ghz is
with the Wi-Fi router Talon AD7200.

[1]
[https://github.com/gsmaxwell/DopplerFi](https://github.com/gsmaxwell/DopplerFi)

[2] [https://github.com/seemoo-lab/nexmon](https://github.com/seemoo-
lab/nexmon)

~~~
X-Istence
UberTooth retails for $120.

------
bfirsh
If you're on a phone, here's an HTML version of the paper: [https://www.arxiv-
vanity.com/papers/1811.10948/](https://www.arxiv-
vanity.com/papers/1811.10948/)

~~~
infogulch
PSA, you can edit any arxiv.org paper url to add "-vanity" before .org and it
redirects you to the arxiv-vanity.com page for that paper.

~~~
halfjew222
I don’t know if I’m whooshing here but I did get a chuckle out of this.

It’s not really redirecting you, aren’t you redirecting it? :P

~~~
infogulch
Well, arxiv-vanity.com uses a different TLD than arxiv.org, and their
respective url schemes are completely different. arxiv-vanity _.org_ is
hosting a redirection site that interprets the arxiv.org path scheme and
redirects you to the correct arxiv-vanity _.com_ url.

I originally bought the arxiv-vanity.org domain and set it up as some rewrite
rules on my personal caddy server. The owner of arxiv-vanity.com thought it
was cool so we got everything transferred over to them now.

------
ajross
OK, that's clever.

But... why are they calling these "Doppler" shifts? A Doppler shift is a
frequency change due to motion of the transmitter relative to the wave medium.
Clearly they're not throwing these radios around. So these are just
"frequency" shifts, right?

~~~
Jeija
Citing from the paper: _We refer the frequency shift satisfying the above
requirements as artificial Doppler shift, implying that it has minimal impact
on existing systems just like Doppler shifts caused by normal movements._

So they're just calling these "Doppler" shifts because they are so small that
they don't really have any effect on the WiFi link, just like real Doppler
shifts should be compensated for, while the tiny frequency shifts still
contain enough information to be picked up by the BLE radio.

------
teknopurge
This is very clever - it's an atomic swap between high-level RF protocols
using specific pieces of the lower-level radio stack that each protocol relies
upon.

This type of hacking fills my cup.

~~~
peter_d_sherman
You hit the nail on the head.

This brings up a side philosophical discussion here about abstraction in
general -- because two abstractions don't appear compatible at the surface
(e.g., WiFi & Bluetooth) doesn't mean that if you go far enough down the
abstraction hierarchy (i.e., RF) - that you can't get them to be.

This is true about Computers, Law, Language, Math, Systems, really any subject
that deals in abstractions... find the "Lowest Common Denominator" and work
from there... (Apples and Oranges, while different things, share the lowest
common denominator of both being fruit, for example...)

~~~
monetus
This is part of why I love llvm's IR so much.

------
gattilorenz
Wow, this is quite ingenious.

I'm not so sure about the practicality, as the authors claim it would be
useful for integrating into existing networks, but it would mean updating the
firmware of the devices (both WiFi and BLE devices) anyway. At that point you
might simply add BLE capabilities to WiFi routers, which takes half the time
or less... or am I missing an obvious use-case here?

~~~
draugadrotten
It seems one use-case would be exfiltrating and C&C of an APT hosted on a wifi
device, where IDS would not see any exfil traffic on the wifi, yet the wifi
device could use the doppler side channel as a covert channel.

------
_underfl0w_
This kinda reminds me of a technique for communicating within the WiFi
frequency spectrum by "backscattering" some existing waves (as I understand
it). Can be used by non-electrical devices IIRC.

It's interesting how we're able to exploit signal overlap - which seems to be
how this works. Disclaimer: I haven't actually read the paper yet.

------
JoachimS
Seriously cool and clever. Probably more for exfiltration than interop between
two types of radio devices for normal userland communication. The same stategy
could be applied to other radios too.

------
killlameme99
Haven't read the whole paper, just the first couple pages and some bits here
and there, however this appears to give enough high level details to get a
good idea of what exactly is happening:

Problem: BLE and WiFi cannot directly communicate with eachother because
standard WiFi hardware cannot decode BLE packets (and vice versa).

Solution: Fortunately, WiFi and BLE work in the same band. The issue is they
have entirely different bandwidths, methods of multiplexing, data rates, etc.
WiFi transmits on a number of 300ish Khz sub-channels with a total bandwidth
of 20 Mhz, while BLE just uses a single couple MHz channel. There are other
hardware issues but this is a larger one.

The "doppler shift" comes in here because both WiFi and BLE have been made
specifically to combat the doppler effect (or other small offsets), and so
both enable firmware to control the frequency offset of the carrier with a
decent sized bandwidth (about 150 kHz but a lot of different numbers get
thrown around, depends on the hardware that's used).

WiFi hardware allows firmware to detect where in it's 20 MHz band a carrier is
being detected, and blue tooth allows firmware to adjust the carrier signal's
frequency offset. So by modulating the carrier frequency of the BLE data can
be bit banged out, and bit banged in by looking at the center frequency of the
strong signal being detected on the WiFi end. There's a bunch of complications
on top of this because of BLE frequency hopping and other jankiness, but I
think this is the just of it.

BLE cannot just look at how much the WiFi signal is shifted to read data from
WiFi, because the WiFi signal bandwidth is too large and no matter how shifted
it is there's always a strong signal everywhere in the couple MHz wide BLE
channel. However, the WiFi preamble just so happens to look slightly different
to BLE depending on the frequency shift applied to the WiFi carrier, because
different WiFi sub-bands overlap the bluetooth band with depending on WiFi
frequency offset. This way, the WiFi can communicate to the BLE device. Again
there seem to be a lot of complications here since this is exceedingly janky,
but it manages to work. This bit banging process abuses some very specific
pieces of the BLE hardware, seems a lot more complicated than the previous
one. The paper of course explains this in more detail but much later.

Result: Communication is possible with these changes, however because of how
hacky it is, it doesn't have great rates. The paper says 6.5 kbps in
interference free and 1.59 kbps in a "crowded" environment. For reference,
this is about 10 times slower than dial up (56 kbps). So no, you're probably
not going to be streaming on bluetooth with this hack quite yet. This makes
sense since you're sending data by modulating the carrier frequency using a
method that's not meant to be updated by firmware nearly fast enough to send
at a decent data rate.

Sorry if some of the details about WiFi and BLE are wrong, I don't know these
protos very well and I'm just going off what I read in the paper and some
quick googles.

