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.
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)?
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.
There are multiple technologies for WPS: signal strength, fingerprinting, propagation models, angle of arrival if there are multiple antennas and time of flight.
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.
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.
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?
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.
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 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...)
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?
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.
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.
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.
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.
This should be the paper, I think: https://www.usenix.org/system/files/conference/nsdi16/nsdi16...