Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #38801 > unrolled thread

How to look up the GPS location of your MAC address or car on the Internet

Back to article view | Back to alt.os.linux

Contents

  How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-13 06:00 +0000
    Re: How to look up the GPS location of your MAC address or car on the Internet "Carlos E.R." <robin_listas@invalid.es> - 2016-09-13 15:34 +0200
      Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-13 16:06 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet Vladimir <niemda@me.com> - 2016-09-13 20:47 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet "Carlos E. R." <robin_listas@invalid.es> - 2016-09-14 00:20 +0200
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-14 04:41 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet William Unruh <unruh@invalid.ca> - 2016-09-14 00:27 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-14 04:41 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Andy Burns <usenet@andyburns.uk> - 2016-09-14 07:35 +0100
            Re: How to look up the GPS location of your MAC address or car on the Internet Frank Slootweg <this@ddress.is.invalid> - 2016-09-14 07:54 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet "Kerr Mudd-John" <admin@127.0.0.1> - 2016-09-15 11:53 +0100
          Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-15 08:45 -0700
            Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-15 08:51 -0700
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:30 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 18:43 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-16 13:04 -0700
                Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 20:23 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-15 08:31 -0700
          Re: How to look up the GPS location of your MAC address or car on the Internet AL <noemail@none.invalid.com> - 2016-09-15 09:49 -0700
            Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:33 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet "Carlos E.R." <robin_listas@invalid.es> - 2016-09-19 19:22 +0200
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:30 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-16 13:16 -0700
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 04:52 +0000
    Re: How to look up the GPS location of your MAC address or car on the Internet William Unruh <unruh@invalid.ca> - 2016-09-14 00:24 +0000
      Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-14 04:40 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet bruce <bruce@invalid.dyndns.tv.invalid> - 2016-09-14 18:41 -0400
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:56 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet bruce <bruce@invalid.dyndns.tv.invalid> - 2016-09-17 16:12 -0400
              Re: How to look up the GPS location of your MAC address or car on the Internet Winston <wbe@UBEBLOCK.psr.com.invalid> - 2016-09-17 19:04 -0400
                Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:43 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 02:30 +0000
                Re: How to look up the GPS location of your MAC address or car on the Internet nospam <nospam@nospam.invalid> - 2016-09-17 22:54 -0400
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:43 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet Winston <wbe@UBEBLOCK.psr.com.invalid> - 2016-09-15 01:04 -0400
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 23:17 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 23:36 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 01:59 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 01:59 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-16 22:22 -0700
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 06:17 +0000
                Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 06:32 +0000
                  Re: How to look up the GPS location of your MAC address or car on the Internet nospam <nospam@nospam.invalid> - 2016-09-17 10:08 -0400
                    Re: How to look up the GPS location of your MAC address or car on the Internet Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-09-17 16:13 +0200
                    Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:43 +0000
                      Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:49 +0000
                        Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 04:00 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 01:59 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 02:00 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#38952

On 2016-09-16 21:33, Horace Algier wrote:
> On Thu, 15 Sep 2016 09:49:06 -0700, AL wrote:
> 
>>> Yep.  Resistance if futile.  You've already been assimilated.
>>
>> And Google is not the only assimilator...  8-O
> 
> The Nordstrom example is interesting, but it's not the mechanism that I'm
> looking at in this question.

wait.

> The question is... under what *other* conditions (other than acting as an
> Access Point) does an iOS or Android mobile device get put into the Google
> Public Database by poorly configured Android devices?

Notice this bit in the article:

«that would scan for smartphones with Wi-Fi turned on and scanning for
networks»

Ie, the sensors only track those smartphones that are searching for
networks. A phone that doesn't search will not be logged, can't be. And
I guess that phones using wifi, ie, clients, can't either.


I don't think that those "poorly configured smartphones" track the
clients of an AP. Too much traffic to be sending possibly over the poor
user dataplan.

On the other hand, google already knows the location of all android
phones, the instant they register. It doesn't need to ask "poorly
configured smartphones" for that data.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#38871

On Thu, 15 Sep 2016 08:31:02 -0700, Jeff Liebermann wrote:

> Note:  No more Q&A from me for a few more days.  I sprained both
> wrists and it hurts to type.

Hi Jeff,
There really is only one question, which is the following:

QUESTION:
- Under what conditions does a cellphone SSID/MAC/SS get put into the 
Google Public API by *other* (poorly configured) Android cellphones?

>>So, my key question is *when* does a mobile device broadcast it's MAC
>>address (BSSID & SSID)?
> 
> The source and destination MAC address of ALL Wi-Fi packets are in the
> 802.11 packet headers.  For broadcasts and management packets, only
> the source MAC address is present.  The address is NOT encrypted. Note
> that all 802.11 Wi-Fi is done on Layer 2 (MAC layer) and does not
> involve Layer 3 (IP layer).

While I realize the *packet* contains the MAC address of the cellphone
2.4GHz and 5GHz radios, what I'm asking is under what contitions *that* MAC
address is handed over to the Google Public Database (along with your SSID,
GPS location, and signal strength) by most poorly configured Android
devices.
 
>>Does a mobile device broadcast its MAC address when acting as a hotspot,
>>for example?
> 
> Yes.  Broadcasts include the source MAC address, but no destination
> MAC address because they go to all devices on the network.  For
> example, an ARP request packet, which asks "which device MAC address
> has this IP address?", includes the MAC address of the device that
> asked for the information, but nothing in the destination field.

This is key!
My whole question is when does the cellphone (whether iOS or Android) get
its MAC address put into the Google Public Database.

The Google Public Database obtains its information from poorly configured
Android devices which hand to Google every day all the public APIs that
these phones encounter (along with the Mac address of the API, the Signal
Strength of the API, and the current GPS location of the cellphone).

So you have confirmed that any cellphone (iOS or Android) which broadcasts
itself as an access point (whether it has security or not), will almost
certainly already be *in* the Google Public Database.

That means that any cellphone broadcasting as an access point will have:
a. Its last GPS location in the Google Public API
b. Its last signal strength in the Google Public API
c. Its MAC address in the Google Public API
d. And its SSID in the Google Public API

So, notice the flaw?
If I know the MAC address of teh ios or Android phone, and I know the MAC
address of the router at the local starbucks, I can query the Google
database to see if the two are in close proximity to each other.

*that* is the tracking I'm discussing.
 
>>Once the MAC address is broadcast as an AP, *all* the (poorly configured)
>>Android devices in the vicinity will throw the user under the bus by
>>handing that MAC address (and much more) to Google's constantly updated
>>database.
> 
> Yep.  Resistance if futile.  You've already been assimilated.

You've confirmed that if the iOS or Android cellphone is broadcasting its
SSID (whether enrypted or not) as an Access Point, then its GPS location,
SSID, BSSID, and Signal Strength is already in the Google Database, because
all poorly configured Android devices that encounter that iOS or Android
cellphone will be reporting it to Google every single day.

However, the question remains:

REMAINING QUESTION:
- Under what *other* conditions (other than broadcasting as an Access
Point) does an iOS or Android cellphone get put into the Google PUblic API
by poorly configrued Android devices?

I can't think of any other circumstances where the iOS or Android device
SSID/MAC/SS? and GPS location will be put into the Google Database, but
that's the question.

Is there any other time, other than when acting as an Access Point, that
the iOS or Android cellphone will have its SSID/MAC/SS & GPS location put
into the Google Public Database by poorly configured Android cellphones?

[toc] | [prev] | [next] | [standalone]

#38876

On Fri, 16 Sep 2016 19:30:07 +0000 (UTC), Horace Algier
<horatio@horatio.net> wrote:

>On Thu, 15 Sep 2016 08:31:02 -0700, Jeff Liebermann wrote:

>>>Does a mobile device broadcast its MAC address when acting as a hotspot,
>>>for example?
>> 
>> Yes.  Broadcasts include the source MAC address, but no destination
>> MAC address because they go to all devices on the network.  For
>> example, an ARP request packet, which asks "which device MAC address
>> has this IP address?", includes the MAC address of the device that
>> asked for the information, but nothing in the destination field.
>
>This is key!
>My whole question is when does the cellphone (whether iOS or Android) get
>its MAC address put into the Google Public Database.

Which MAC address?  A cell phone can easily have several.  Instead of
a cell phone, look at the web page setup for a typical home router.
Each interface has a MAC address.  There's one for the WAN port, 4
addresses one each for the LAN ports, and 1 for the Wi-Fi port which
is actually a 5th port on the ethernet switch.  Often, 3 of these
numbers are printed on a sticker near the serial number tag.

When some of these functions are performed by a cell phone, only a few
of these MAC addresses will be publicly accessible.  Since the traffic
is moving by wi-fi, the wi-fi port MAC address can be logged.  Since
the phone is acting as a bridge between wi-fi and cellular data,
methinks there should be another MAC address on the wireless data
port.  That address does NOT go throught the wi-fi to cellular data
bridge, so it will NOT be accessible.  So, the answer is that only the
MAC address of the wi-fi device get harvested.  Turning the wi-fi
device into a software access point doesn't hide anything because the
wi-fi device MAC address has to be exposed no matter what software is
using it to move data.

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]

#38895

On Fri, 16 Sep 2016 13:16:49 -0700, Jeff Liebermann wrote:

> Which MAC address? 

The only MAC address that matters is the MAC address that is harvested by 
poorly configured Android devices.

We *know* that poorly configured Android devices harvest the SSID of all 
access points that they encounter, and along with the SSID, these poorly 
configured Android devices also harvest the MAC ADDRESS of the access point 
(both 2.4GHz and 5GHz MAC addresses) and they also harvest the signal 
strength of each access point. In addition, they know their own location, 
so they give Google the GPS of their location along with that access point 
data above.

See this:
https://blog.ouseful.info/2016/01/27/looking-up-the-physical-location-of-your-wifi-router/

Which refers to the canonical Geolocation API from Google:
https://developers.google.com/maps/documentation/geolocation/intro

Notice all you need is:
1. BSSID 1
2. BSSID 2
3. Signal Strength

> the answer is that only the
> MAC address of the wi-fi device get harvested.  Turning the wi-fi
> device into a software access point doesn't hide anything because the
> wi-fi device MAC address has to be exposed no matter what software is
> using it to move data.

I think there is a difference between the MAC address of teh WiFi devices 
(5GHz and 2.4GHz) being sent in the clear in the *packets* and the MAC 
address of the WiFi devices (5GHz and 2.4GHz) being sent as an Access Point 
*broadcast*.

Google *says* they don't harvest hidden access points, and Google says 
they'll drop non-hidden access points with "_nomac" in the SSID - but other 
than those two protections, it seems that Google allows all poorly 
configured Android devices to harvest *your* access point SSID and BSSID 
and Signal Strength, along with the GPS coordinates of the poorly 
configured Android device, many times a day (all in the background).

Given that, I think the answers to my questions are:

Q1: When do poorly configured Android devices harvest "your" cellphone 
SSID/MAC/SS & GPS? 
A1: Only when your cellphone is set as an non-hidden access point.

Q2: What information is needed to figure out if a cellphone is at the local 
starbucks at this very moment?
A2: You first must set the cellphone into being an access point, and then 
all you need to do is query the Google Public API for three things:
a. The BSSID of the cellphone access point
b. The BSSID of the local starbucks
c. Some bogus Signal Strength data that implies they're close together

If they *are* close together, then some poorly configured Android device 
would already have thrown them under the bus and they'd be in the Google 
Public API which you just queried.

[toc] | [prev] | [next] | [standalone]

#38818

On 2016-09-13, Horace Algier <horatio@horatio.net> wrote:
> If you know the MAC address of your equipment (e.g., automotive WiFi 
> beacons), and the MAC address of someone else's equipment, how can you look 
> up *where* your phone currently is?

You cannot. There is no necessary relationship between IP addresses and
location. Now often there is some rough correlation, but that is all you
can do. 

>
> I know that a public free easily accessible Google API maintains that 
> information, where if you know the MAC address of the person you're trying 
> to track, you can find out instantly if two MAC addresses are near each 
> other from anywhere in the world:
> https://developers.google.com/maps/documentation/geolocation/intro

Nope.

>
> For the Google lookup, the only *mandatory* parameters are:
> 1. MAC ADDRESS #1
> 2. MAC ADDRESS #2
> 3. A fabricated signal-strength value

	 Except for fun, I would not rely on it. 
As a trivial example, lets say I run a VPN from Vancouver to Italy. My
IP will probably be an Italian one as far as the world is concerned. My
computer however is in Vancouver. 

>
> However, there must be *other* MAC-address GPS-location lookup engines on 
> the net, for example, you can track vehicle beacons here:
> https://wigle.net
>
> Do you know of other MAC address location lookup engines?

[toc] | [prev] | [next] | [standalone]

#38820

On Wed, 14 Sep 2016 00:24:59 -0000 (UTC), William Unruh wrote:

>> If you know the MAC address of your equipment (e.g., automotive WiFi 
>> beacons), and the MAC address of someone else's equipment, how can you look 
>> up *where* your phone currently is?
> 
> You cannot. There is no necessary relationship between IP addresses and
> location. Now often there is some rough correlation, but that is all you
> can do. 

I realize you're trying to help, so I will just try to be gentle at the
same time I'm trying to be blunt (you can do the same with me).

Nobody said anything about IP addresses.
And the *location* is inside of Google's database.

What I'm trying to understand is how the system works.
And then I'm trying to see if there is a *vulnerability* in the system.

I'm not a hacker (as a hacker would have far more technical acumen and a
hacker wouldn't be asking about a vulnerability on the net like this).

What I see is a *vulnerability* but you're *never* gonna see that
vulnerability if you keep talking about IP addresses!

>> I know that a public free easily accessible Google API maintains that 
>> information, where if you know the MAC address of the person you're trying 
>> to track, you can find out instantly if two MAC addresses are near each 
>> other from anywhere in the world:
>> https://developers.google.com/maps/documentation/geolocation/intro
> 
> Nope.

I realize you're trying to help, but just saying "Nope" wastes *everyone's*
time, including yours and mine - but mostly other people have to read me
responding to you, which, if all you say is "Nope" means you don't have a
clue what you're talking about.

It's a *fact* that you can query Google's database to find the *location*
of a BSSID. Google implemented a (IMHO weak) "security" system by requiring
*two* BSSIDs.

It's this weak security that I'm searching for the vulnerability of.

It's a *fact* that you only need three things to get a GPS location out of
the Google database:
1. BSSID 1
2. BSSID 2 (added as a weak security feature!)
3. Signal Strength

Do you dispute *that* fact?

>> For the Google lookup, the only *mandatory* parameters are:
>> 1. MAC ADDRESS #1
>> 2. MAC ADDRESS #2
>> 3. A fabricated signal-strength value
> 
> 	 Except for fun, I would not rely on it.

That's not at all the point!
I am probing a perceived privacy vulnerability in the Google system.
I am doing this not to take advantage of that perceived vulnerability, but
to better *understand* that privacy vulnerability.

Specifically, with the facts known, "if" your cellphone does broadcast an
SSID, then your cellphone *can* be tracked.

Do you dispute that statement (which I have backed up in gory detail
already)?

Why or why not?
 
> As a trivial example, lets say I run a VPN from Vancouver to Italy.

*[Where is Jeff LIebermann when we need him?]*


What on earth does this question have to do with IP addresses?

I realize you're trying to help - but what you're doing is *jumping* to
conclusions that *nobody* else is talking about.

VPN has *nothing* whatsoever to do with this problem.
The entire Internet has (almost) nothing whatsoever to do with this
problem.

The *only* way the Internet is even involved is that your neighbor's
cellphone is *sending* your SSID & MAC & GPS location & Signal Strength
(etc) of your router *over* the Internet to Google.

So the IP address (and VPN) is completely irrelevant to this question.

>  My
> IP will probably be an Italian one as far as the world is concerned. My
> computer however is in Vancouver. 

This question has absolutely nothing to do with IP addresses and VPNs.
Where did you get the idea that the question had *anything* to do with the
Internet?
I'm sorry if I'm being too blunt, but I'm focused on getting the answer to
a *simple* question.

Q: When does an Android cellphone broadcast an SSID?

NOTE: The SSID has nothing to do with the question but people get all hung
up if I ask the question this way:

Q: When does an Android cellphone broadcast a BSSID?

[toc] | [prev] | [next] | [standalone]

#38833

> This question has absolutely nothing to do with IP addresses and VPNs.
> Where did you get the idea that the question had *anything* to do with the
> Internet?
> I'm sorry if I'm being too blunt, but I'm focused on getting the answer to
> a *simple* question.
>
> Q: When does an Android cellphone broadcast an SSID?
>
> NOTE: The SSID has nothing to do with the question but people get all hung
> up if I ask the question this way:
>
> Q: When does an Android cellphone broadcast a BSSID?

Oh, what the hell.  I'll give it a try.

In the following I tend to intersperse WAN and LAN as well as BSSID and
MAC.  The basic underlying concepts work in both environments (with some
fudging).

SSID has nothing to do with cellphones.  It has to do with wifi only.
The same is true for BSSID.

SSID is just a name.  There could be thousands of wifi access points
around the world with the same SSID.

A wifi access point consists of one or more radios to create a WAN.
Each radio is a BSS with a BSSID, which is also known as a MAC.  Each
network device/radio has (by design, but not always in fact) a unique
value for the MAC.

A device wishing to connect to a wifi access point looks for a broadcast
wifi packet with a particular SSID in the data field of the packet.  The
header to the packet contains the BSSID/MAC of the access point in
source field.  To connect to the access point the device sends a packet
back to the sender of the broadcast by putting the access point's BSSID
in the destination field of the packet and its own MAC in the source
field.  The rest of the connection protocol is left as an exercise for
the reader.

Until things get handed over to (presumably) DHCP there is no way to
communicate other than the use of MAC addresses in the appropriate
fields of the LAN packets.  Strictly speaking, even after an IP address
is assigned to the device, all communications on the LAN/WAN is still
through the use of BSSID/MAC.  It is only after a packet is recieved by
the router that higher levels of network communications kick in and a
packet will be repackaged with the necessary outer packet to make its
way to the internet.

So, "Q: When does an Android cellphone broadcast an SSID?"

A: Keying on the use of the word "broadcast" and ignoring the use of the
   word "cellphone" because it doesn't apply, only when it is acting as
   its own access point/hot-spot for other devices.  After all, an SSID
   is only a name.

And, "Q: When does an Android cellphone broadcast a BSSID?"

A: Again, keying on the use of the word "broadcast" and ignoring the
   word "cellphone" the answer is the same as for the previous question.
   However, as mentioned earlier, the MAC/BSSID is used in every packet
   that is sent back and forth with the access point, but is strictly
   usable only within the geographic area that the radio signals reach,
   which is pretty much limited to line of sight communications and for
   which walls are only semi-transparent at those frequencies.

Now, with all that said, there is in theory nothing to stop any program
running as part of the wifi access point or within the connecting device
to query its own networking internals to grab its own MAC address or the
MAC address of devices it is communicating with and send that info out
onto the internet to some recipient along with info from its own GPS, if
available.

So, while it is not part of the normal protocols to reveal that
information it is not inconceivable that some user level program could
be doing the nasty deed.

Furthermore, all of this is at best fleeting information because a
network device's MAC address is held in ROM on the device.  The network
software in a device reads the ROM to get the MAC, but is in no way
required to use that address when constructing packets that will go out
the device.  The device itself *DOES NOT* insert the address into the
outgoing packets.  That is all handled by software.  Therefore it is
trivial for the software to use whatever MAC address it wants for its
outgoing packets.  This is in fact how DECnet used to work, the two high
order bytes of the MAC were changed to reflect the fact that a packet
was a DECnet packet.

As was said before, just flip a few bits and you could suddenly appear
to be on the other side of the planet.

Whew!

Now, what has been left out?  Oh yes, the cellphone network.  How data
is sent over the cellphone network is probably off topic for most of the
newsgroups listed above.  Therefore, I suggest you redirect your
queries/confusions to more appropriate groups.

Bruce             .

-- 

[toc] | [prev] | [next] | [standalone]

#38874

On Wed, 14 Sep 2016 18:41:22 -0400, bruce wrote:

> Oh, what the hell.  I'll give it a try.

Thanks Bruce. I'm always nice if someone is sincerely trying to answer the 
question, and, I do realize that most people don't even *understand* the 
question.

> In the following I tend to intersperse WAN and LAN as well as BSSID and
> MAC.  The basic underlying concepts work in both environments (with some
> fudging).

All we care about, for *this* discussion, is the MAC address of the 5GHz 
and 2.4GHz radios in the iOS or Android cellphones we are trying to track.

That MAC address is also called a BSSID.

Google also logs the SSID, the signal strength, and the GPS location, but 
they are not of importance for *this* discussion.

Only the MAC address (aka BSSID) is important for *this* discussion.

> SSID has nothing to do with cellphones.  It has to do with wifi only.
> The same is true for BSSID.

This is not true that "SSID has nothing to do with cellphones".

As Jeff and I just discussed, if an Android or iOS cellphone acts as an 
Access Point, then that cellphone will broadcast an SSID.

If that iOS or Android cellphone broadcasts an SSID, it also broadcasts a 
BSSID, which is unique to that cellphone. In fact, it broadcasts *two* 
BSSIDs, one for each radio (5Ghz and 2.4Ghz). 

It's *those* unique BSSIDs which are captured by poorly configured Android 
devices and uploaded multiple times a day to the Google Public Database, 
along with the GPS location of the poorly configured Android device and the 
SSID and Signal Strength of the access point.

Notice this allows such iOS or Android cellphones to be tracked!

> SSID is just a name.  There could be thousands of wifi access points
> around the world with the same SSID.

I agree. SSID is "just a name". If the name ends with "_nomac", Google 
promises to *drop* that SSID from its' public database.

However, you must realize that the Google Public Database contains *more* 
than the SSID! It contains the *unique* BSSID associated with that SSID, 
and furthermore, it contains the Signal Strength of that access point at a 
specific GPS location of the poorly configured Android device that is near 
that access point.

Anyone who doesn't *understand* that paragraph above can't possibly 
understand the topic of this thread - so it's critical that the paragraph 
above be *understood*.
 
> A wifi access point consists of one or more radios to create a WAN.
> Each radio is a BSS with a BSSID, which is also known as a MAC.  Each
> network device/radio has (by design, but not always in fact) a unique
> value for the MAC.

I agree. Specifically, if an iOS or ANdroid cellphone is acting as an 
access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
a. The cellphone AP SSID
b. The cellphone AP BSSID

What you must understand to understand the question, is that poorly 
configured Android devices will *send* to Google not only that information 
above, but *more* information!

Poorly configured Android devices will send to Google:
a. Your cellphone AP SSID
b. Your cellphone AP BSSID (aka MAC address)
c. Your AP signal strength seen by the poorly configured Android cellphone
d. The GPS location of the poorly configured Android cellpone

> A device wishing to connect to a wifi access point looks for a broadcast
> wifi packet with a particular SSID in the data field of the packet.  The
> header to the packet contains the BSSID/MAC of the access point in
> source field.  To connect to the access point the device sends a packet
> back to the sender of the broadcast by putting the access point's BSSID
> in the destination field of the packet and its own MAC in the source
> field.  The rest of the connection protocol is left as an exercise for
> the reader.

This part is understood that the BSSID of the 5Ghz and 2.4GHz radios in 
both iOS and Android devices is sent in the clear in packets whenever those 
cellphones connect to an access point.

But I'm not talking about that.

I'm only talking about when an iOS or Android cellphone has the following 
four bits of information *sent* to the Google database by poorly configured 
Android devices:
a. Your cellphone AP SSID
b. Your cellphone AP BSSID (aka MAC address)
c. Your AP signal strength seen by the poorly configured Android cellphone
d. The GPS location of the poorly configured Android cellpone

> Now, with all that said, there is in theory nothing to stop any program
> running as part of the wifi access point or within the connecting device
> to query its own networking internals to grab its own MAC address or the
> MAC address of devices it is communicating with and send that info out
> onto the internet to some recipient along with info from its own GPS, if
> available.

Yes. You are correct that there are *other* methods, other than the Google 
Public Database, to obtain MAC addresses of devices.

For example, this web site from wardriving software:
https://wigle.net/

But *this* question is complex enough for most people (almost nobody 
understood the question) if I simply stick to the Google mechanism.

Lord knows how complex this question gets if I bring in the Wigle 
wardriving mechanism (which even I don't understand).

> So, while it is not part of the normal protocols to reveal that
> information it is not inconceivable that some user level program could
> be doing the nasty deed.

Yep. Wardrivign software.
Or anything from Marius Milner (e.g., netstumbler).

> Furthermore, all of this is at best fleeting information because a
> network device's MAC address is held in ROM on the device.  The network
> software in a device reads the ROM to get the MAC, but is in no way
> required to use that address when constructing packets that will go out
> the device.  The device itself *DOES NOT* insert the address into the
> outgoing packets.  That is all handled by software.  Therefore it is
> trivial for the software to use whatever MAC address it wants for its
> outgoing packets.  This is in fact how DECnet used to work, the two high
> order bytes of the MAC were changed to reflect the fact that a packet
> was a DECnet packet.

This is not true.
Jeff Liebermann explained in the past why it would take an heroic effort to 
clone the MAC address of the radio that is sending out the packets.

The cloning is on a different MAC address, which is not the MAC address of 
concern here.

Too bad, becuase if it were easy to change the Access Point MAC address, 
then I would change mine daily.

> As was said before, just flip a few bits and you could suddenly appear
> to be on the other side of the planet.

Not true.
You're confusing the easily cloned MAC address with the one that would take 
desoldering to change.

[toc] | [prev] | [next] | [standalone]

#38923

Horace Algier <horatio@horatio.net> writes:

I purposely kept my earlier post at a fairly high level, mostly because
from your other posts I was left with the opinion that you weren't
handling the information you were presented with very well.  I attempted
to provide some background for the discussion so that we could at least
agree on the meaning of various terms and the concepts that use those
terms.

While your reply was cordial, for the most part, you did with me as you
have done with others, namely rejected statements which are easily
verified as true.

> On Wed, 14 Sep 2016 18:41:22 -0400, bruce wrote:
>
>> Oh, what the hell.  I'll give it a try.
>
> Thanks Bruce. I'm always nice if someone is sincerely trying to answer
> the question, and, I do realize that most people don't even
> *understand* the question.
>
>> In the following I tend to intersperse WAN and LAN as well as BSSID
>> and MAC.  The basic underlying concepts work in both environments
>> (with some fudging).

Again, here I was attepting to lay a background.

>
> All we care about, for *this* discussion, is the MAC address of the
> 5GHz and 2.4GHz radios in the iOS or Android cellphones we are trying
> to track.
>
> That MAC address is also called a BSSID.
>
> Google also logs the SSID, the signal strength, and the GPS location,
> but they are not of importance for *this* discussion.
>
> Only the MAC address (aka BSSID) is important for *this* discussion.

And here you are trying to bore down to a lower level prematurely, IMHO.

>> SSID has nothing to do with cellphones.  It has to do with wifi only.
>> The same is true for BSSID.
>
> This is not true that "SSID has nothing to do with cellphones".

Yes, I'm afraid it is true.  To reject it implies that you believe that
all cellphones do wifi.  I have two on the shelf in this room that do
not do and never did do wifi.

> As Jeff and I just discussed, if an Android or iOS cellphone acts as
> an Access Point, then that cellphone will broadcast an SSID.

This is consistent with what I wrote above and what I wrote below.  This
action has nothing to do with it being a cellphone but to do with it
acting at this point as a wifi device.

> If that iOS or Android cellphone broadcasts an SSID, it also
> broadcasts a BSSID, which is unique to that cellphone.  

Not necessarily.  The protocols allow the creation of a BSSID on the
fly.  It only has to be unique within the (very short) range of the
radios in use.

>                                                         In fact, it
> broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).

Actually, any wifi device acting as a BSS can identify itself as up to
32 BSSIDs and 1 or more SSIDs per radio.  So, yes, a single radio can
simultaneously be using 32 different BSSIDs/MACs.

> It's *those* unique BSSIDs which are captured by poorly configured
> Android devices and uploaded multiple times a day to the Google Public
> Database, along with the GPS location of the poorly configured Android
> device and the SSID and Signal Strength of the access point.

As I said below, poorly configured has nothing to do with it when any
user level program running on the BSS or within the cellphone can access
the very same wifi information and pass it on to whomever it wishes.

> Notice this allows such iOS or Android cellphones to be tracked!

Did I ever say anything to contradict this?  I merely pointed out that
cellphone configuration, if done "properly" (whatever that means) won't
cure the problem when user level code running on the equipment can
accomplish the same thing.  In fact, it might be through user level code
that it is being accomplished right now.

>> SSID is just a name.  There could be thousands of wifi access points
>> around the world with the same SSID.
>
> I agree. SSID is "just a name". If the name ends with "_nomac", Google 
> promises to *drop* that SSID from its' public database.

While Google might honor the use of the suffix (for now) it doesn't mean
that anybody else will.

> However, you must realize that the Google Public Database contains
> *more* than the SSID! It contains the *unique* BSSID associated with
> that SSID, and furthermore, it contains the Signal Strength of that
> access point at a specific GPS location of the poorly configured
> Android device that is near that access point.
>
> Anyone who doesn't *understand* that paragraph above can't possibly 
> understand the topic of this thread - so it's critical that the paragraph 
> above be *understood*.

That "paragraph above" means absolutely nothing until one understands
that even in a "properly configured" phone user level code could be
gathering the same information (or more) and sending it to agents
unknown. 
  
>> A wifi access point consists of one or more radios to create a WAN.
>> Each radio is a BSS with a BSSID, which is also known as a MAC.  Each
>> network device/radio has (by design, but not always in fact) a unique
>> value for the MAC.
>
> I agree. Specifically, if an iOS or ANdroid cellphone is acting as an 
> access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
> a. The cellphone AP SSID
> b. The cellphone AP BSSID
>
> What you must understand to understand the question, is that poorly 
> configured Android devices will *send* to Google not only that information 
> above, but *more* information!
>
> Poorly configured Android devices will send to Google:
> a. Your cellphone AP SSID
> b. Your cellphone AP BSSID (aka MAC address)
> c. Your AP signal strength seen by the poorly configured Android cellphone
> d. The GPS location of the poorly configured Android cellpone

As stated above, poorly configured is not the problem, and Google might
not be the only recipient.

>> A device wishing to connect to a wifi access point looks for a
>> broadcast wifi packet with a particular SSID in the data field of the
>> packet.  The header to the packet contains the BSSID/MAC of the
>> access point in source field.  To connect to the access point the
>> device sends a packet back to the sender of the broadcast by putting
>> the access point's BSSID in the destination field of the packet and
>> its own MAC in the source field.  The rest of the connection protocol
>> is left as an exercise for the reader.
>
> This part is understood that the BSSID of the 5Ghz and 2.4GHz radios
> in both iOS and Android devices is sent in the clear in packets
> whenever those cellphones connect to an access point.
>
> But I'm not talking about that.
>
> I'm only talking about when an iOS or Android cellphone has the
> following four bits of information *sent* to the Google database by
> poorly configured
> Android devices:
> a. Your cellphone AP SSID
> b. Your cellphone AP BSSID (aka MAC address)
> c. Your AP signal strength seen by the poorly configured Android
>     cellphone
> d. The GPS location of the poorly configured Android cellpone

Get off this poorly configured fixation you have.  A perfect config-
uration with any amount of user-level programs has potentially the same
nasty possibilities.

>> Now, with all that said, there is in theory nothing to stop any
>> program running as part of the wifi access point or within the
>> connecting device to query its own networking internals to grab its
>> own MAC address or the MAC address of devices it is communicating
>> with and send that info out onto the internet to some recipient along
>> with info from its own GPS, if available.
>
> Yes. You are correct that there are *other* methods, other than the
> Google Public Database, to obtain MAC addresses of devices.
>
> For example, this web site from wardriving software:
> https://wigle.net/
>
> But *this* question is complex enough for most people (almost nobody 
> understood the question) if I simply stick to the Google mechanism.
>
> Lord knows how complex this question gets if I bring in the Wigle 
> wardriving mechanism (which even I don't understand).
>
>> So, while it is not part of the normal protocols to reveal that
>> information it is not inconceivable that some user level program
>> could be doing the nasty deed.
>
> Yep. Wardrivign software.
> Or anything from Marius Milner (e.g., netstumbler).

Or maybe even "Angry Birds" does this too!

>> Furthermore, all of this is at best fleeting information because a
>> network device's MAC address is held in ROM on the device.  The
>> network software in a device reads the ROM to get the MAC, but is in
>> no way required to use that address when constructing packets that
>> will go out the device.  The device itself *DOES NOT* insert the
>> address into the outgoing packets.  That is all handled by software.
>> Therefore it is trivial for the software to use whatever MAC address
>> it wants for its outgoing packets.  This is in fact how DECnet used
>> to work, the two high order bytes of the MAC were changed to reflect
>> the fact that a packet was a DECnet packet.
>
> This is not true.

Actually, you are partially correct.  DECnet changes the leading four
octets (notice, the proper term is octets, not bytes; I was too casual
in the above paragraph) to "AA 00 04 00".  The remaining 2 octets make
up the node within a DECnet network.  How do I know this?  I'm an
ex-DECie.  (Actually, I'm still a DECie but they don't pay me anymore.)
If you want a reference on this a brief desctiption may be found at
<https://en.wikipedia.org/wiki/DECnet> which contains the following:

    "The Ethernet implementation was unusual in that the software
     changed the physical address of the Ethernet interface on the
     network to AA-00-04-00-xx-yy where xx-yy reflected the DECnet
     network address of the host.  This allowed ARP-less LAN operation
     because the LAN address could be deduced from the DECnet address."

I've avoided making any references to 802 so far here.  And my DECnet
references mostly concern(ed) 802.3, 802.<whatever> all have the same
underpinnings.  DEC was one of three companies that colaboratively
"invented" ethernet (at least the hardware specs, that is).  The origin
of ethernet comes from the amateur radio two meter band protocols used
in Hawaii, which was called "Aloha Net".

> Jeff Liebermann explained in the past why it would take an heroic
> effort to clone the MAC address of the radio that is sending out the
> packets.

Without reference I can not comment on this, but what I'm talking about
for MAC has nothing to do with cloning.

> The cloning is on a different MAC address, which is not the MAC
> address of concern here.

Huh?  

> Too bad, becuase if it were easy to change the Access Point MAC
> address, then I would change mine daily.

You might want to look into this then.

>> As was said before, just flip a few bits and you could suddenly
>> appear to be on the other side of the planet.
>
> Not true.
> You're confusing the easily cloned MAC address with the one that would
> take desoldering to change.

That statement is most definately true.  I can assure you that when a
VAX computer was moved from one location to another nobody went running
for a soldering iron.

If changing the MAC address (also called the hardware address) was so
difficult, why do you suppose the capability exist in ifconfig(8) to
change it?

Bruce                        .

-- 

[toc] | [prev] | [next] | [standalone]

#38931

Horace Algier <horatio@horatio.net> wrote:
>> The cloning is on a different MAC address, which is not the MAC
>> address of concern here.

bruce <bruce@invalid.dyndns.tv.invalid> replied:
> Huh?  

Referring to a typical consumer-grade wireless router, I believe he
meant that cloning a MAC address usually was to change the WAN MAC
address, whereas he was discussing the WLAN MAC address, which (at the
time he wrote that) he thought couldn't be changed without hardware
mods.  I think he has since learned that WLAN MAC addresses are, in
general, set via software from saved configuration.

There are many consumer-class routers I've never dealt with, so I don't
know if he's right in thinking that the manufacturer's firmware for some
routers does not support changing the WLAN MAC address.

Elsewhere I said I don't see this as big issue.  Even when the WLAN MAC
address can be changed, in practice, for most routers out there, my
impression is that once the router's been configured, the WLAN MAC
address one sees at a particular location generally won't change unless
the router gets replaced.
 -WBE

[toc] | [prev] | [next] | [standalone]

#38943

On Sat, 17 Sep 2016 19:04:01 -0400, Winston wrote:

> Referring to a typical consumer-grade wireless router, I believe he
> meant that cloning a MAC address usually was to change the WAN MAC
> address, whereas he was discussing the WLAN MAC address, which (at the
> time he wrote that) he thought couldn't be changed without hardware
> mods.  

This is correct.

Everyone knows how to clone the "WAN MAC Address", which is as simply as
pressing a button and typing "DE:AD:BE:EF:CA:FE".

It's the WLAN MAC address which doesn't have a "clone" button in the
manufacturers' software/firmware.

> I think he has since learned that WLAN MAC addresses are, in
> general, set via software from saved configuration.

I think what Jeff Liebermann was saying was that, for *routers*, you can
change the WLAN MAC Address if you use the right custom firmware.

But we were talking about phones, so, Jeff also added that for Android
phones, you can change the WLAN MAC address if you're root using the
typical Linux commands we use all the time on Linux.

The situation would be likewise for jailbroken iOS phones, with the
exception that, in practice, Apple seems to prevent that with each iOS
upgrade, so, effecitvely, you can't change the WLAN MAC address easily on
an iOS phone.

> There are many consumer-class routers I've never dealt with, so I don't
> know if he's right in thinking that the manufacturer's firmware for some
> routers does not support changing the WLAN MAC address.

I got all my information from Jeff - who told me, a couple of years ago,
that the "clone" in the consumer-class routers is for the wrong MAC
address.

The only MAC address that matters, for this discussion, is the MAC address
that the poorly configured Android devices in the vicinity are *uploading*
to the Google PUblic database.

> Elsewhere I said I don't see this as big issue.  Even when the WLAN MAC
> address can be changed, in practice, for most routers out there, my
> impression is that once the router's been configured, the WLAN MAC
> address one sees at a particular location generally won't change unless
> the router gets replaced.

While what you're saying is true, that people don't change their WLAN Mac
addresses even if they could, I have used only Netgear and Linksys and
D-Link routers, and *none* of them have allowed me to change the one MAC
address that matters for this discussion, which is the MAC address that is
*uploaded* to the Google Public Database by poorly configured Android
devices in the vicinity.

The main question is:
1. Under what circumstances is an iOS or Android *phone's* MAC address
*uploaded* to the Google PUblic Database by poorly configured Android
devices in the vicinity?

2. How can someone *exploit* that fact to locate the phone?

[toc] | [prev] | [next] | [standalone]

#38940

On Sat, 17 Sep 2016 16:12:40 -0400, bruce wrote:

>> This is not true that "SSID has nothing to do with cellphones".
> 
> Yes, I'm afraid it is true.  To reject it implies that you believe that
> all cellphones do wifi.  I have two on the shelf in this room that do
> not do and never did do wifi.

OK. You found a corner case, where not all cellphones do WiFi.
Since I also have iOS equipoment, all my iOS equipment has WiFi also.

While I am sure they exist, I personally have never seen a cellphone that 
doesn't do WiFi; but I also have a limit on cellphones of 16GB minimum, 
1GHz minimum, 1GB RAM minimum, etc., where the cost is never below $200 so, 
the cellphones "I" have bought *all* have WiFi.

I did goof with the wife's $200 Moto G, which only has 2.4GHz WiFi, since I 
simply *assumed* that all of the WiFi cellphones had *both* 2.4GHz and 5GHz 
WiFi ... so I agree with you on the wide range of what Android phones do.

>> As Jeff and I just discussed, if an Android or iOS cellphone acts as
>> an Access Point, then that cellphone will broadcast an SSID.
> 
> This is consistent with what I wrote above and what I wrote below.  This
> action has nothing to do with it being a cellphone but to do with it
> acting at this point as a wifi device.

I think here is where we get mired in conflicting details, which are better 
discussed in person, because the mere fact that the BSSID is encapsulated 
in the clear in the WiFi packet is *absolutely meaningless* for the purpose 
of this discussion *if* all those poorly configured Android devices don't 
*upload* that BSSID to the Google Public Database.

The *only* BSSID that matters for this discussion is the BSSID which is 
*uploaded* to the Google Public Database by all those poorly configured 
Android devices.

>> If that iOS or Android cellphone broadcasts an SSID, it also
>> broadcasts a BSSID, which is unique to that cellphone.  
> 
> Not necessarily.  The protocols allow the creation of a BSSID on the
> fly.  It only has to be unique within the (very short) range of the
> radios in use.

I'm completely and intimately familiar with the fact that the BSSID only 
has to be unique on the subnet, e.g., you can use DE:AD:BE:EF:CA:FE on your 
own network and it won't matter, as long as only a single device on your 
network has that BSSID.

Up until Jeff's later responses, I had thought that the BSSID that matters 
(which is the one *uploaded* to the Google database by poorly configured 
Android devices!) was hard to change, and it is, for a typical 
factory-software router.

But Jeff explained that certain firmware will enable that all-important 
BSSID (which is the one that is *uploaded* to the Google database by poorly 
configured Android devices) *can* be changed on a router.

In addition, Jeff noted that, for Android devices which are *rooted*, that 
all-important BSSID (which is the one *uploaded* to the Google publid 
database by poorly configured Android devices) *can* be changed.

Unfortunately, a quick search on Google shows a history of Apple *breaking* 
any jailbroken device's ability to change that specific BSSID with each new 
OS version - so we can effectively say it can't easily be done on iOS 
(which is another reason why iOS has less privacy than Android in certain 
situtations).

>> In fact, it
>> broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).
> 
> Actually, any wifi device acting as a BSS can identify itself as up to
> 32 BSSIDs and 1 or more SSIDs per radio.  So, yes, a single radio can
> simultaneously be using 32 different BSSIDs/MACs.

Are you saying that you have 32 different access points in "a single 
radio"?

It's possible - but remember, the *only BSSID that matters* for this 
conversation is the one that is *uploaded* to the Google Public Database by 
poorly configured Android devices.

All other BSSIDs are meaningless for the purpose of this discussion.

Given that, are you saying that you have *32* different SSIDs which are 
being uploaded, as we speak, to the Google Public Database by all poorly 
configured Android devices in your vicinity?
 
>> It's *those* unique BSSIDs which are captured by poorly configured
>> Android devices and uploaded multiple times a day to the Google Public
>> Database, along with the GPS location of the poorly configured Android
>> device and the SSID and Signal Strength of the access point.
> 
> As I said below, poorly configured has nothing to do with it when any
> user level program running on the BSS or within the cellphone can access
> the very same wifi information and pass it on to whomever it wishes.

I see why you are frustrated in this conversation.

Jeff already noted that there are *plenty* of situations where a BSSID is 
found, in the clear, in the context of WiFi communications.

Since *this* discussion is *only* about exploring privacy flaws in the 
Google Public Database, the only BSSID that matters for this discussion is 
the BSSID that is *uploaded* to the Google Public Database by all poorly 
configured Android devices in your vicinity.

[toc] | [prev] | [next] | [standalone]

#38941

In article <nrku8g$9od$1@news.mixmin.net>, Horace Algier
<horatio@horatio.net> wrote:

> >> This is not true that "SSID has nothing to do with cellphones".
> > 
> > Yes, I'm afraid it is true.  To reject it implies that you believe that
> > all cellphones do wifi.  I have two on the shelf in this room that do
> > not do and never did do wifi.
> 
> OK. You found a corner case, where not all cellphones do WiFi.
> Since I also have iOS equipoment, all my iOS equipment has WiFi also.
> 
> While I am sure they exist, I personally have never seen a cellphone that 
> doesn't do WiFi; 

this one doesn't:
<https://admin.mashable.com/wp-content/uploads/2014/03/motorola-dynatac-
8000x1.jpg>

[toc] | [prev] | [next] | [standalone]

#38944

On Sat, 17 Sep 2016 16:12:40 -0400, bruce wrote:

>> Notice this allows such iOS or Android cellphones to be tracked!
> 
> Did I ever say anything to contradict this?  I merely pointed out that
> cellphone configuration, if done "properly" (whatever that means) won't
> cure the problem when user level code running on the equipment can
> accomplish the same thing.  In fact, it might be through user level code
> that it is being accomplished right now.

Since *this* discussion is *only* about exploring privacy flaws in the 
Google Public Database, the only BSSID that matters for this discussion is 
the BSSID that is *uploaded* to the Google Public Database by all poorly 
configured Android devices in your vicinity.

>>> SSID is just a name.  There could be thousands of wifi access points
>>> around the world with the same SSID.
>>
>> I agree. SSID is "just a name". If the name ends with "_nomac", Google 
>> promises to *drop* that SSID from its' public database.
> 
> While Google might honor the use of the suffix (for now) it doesn't mean
> that anybody else will.

It's even worse than that.
1. While we all know that *hiding* the SSID is futile, it's actually 
*useful* to hide your SSID in that the poorly configured Android devices 
apparently do *not* upload "hidden" SSIDs to the Google Public Database.

2. However, most of us don't "hide" our SSID from being broadcast (since 
there is almost zero security value in hiding the SSID broadcast).

3. Hence, our SSIDs are being *uploaded* to the Google Public Database by 
poorly configured Android devices whether or not we have "_nomac" at the 
end of the SSID.

4. What's worse, the *unique* BSSID of the radio is also uploaded at the 
same time (along with the signal strength of the SSID and the current GPS 
location of the poorly configured Android device).

Therefore, the SSID is the *least* of our privacy worries (unless we're 
dumb enough to name our SSID after our first and last name or something 
similarly identifiable).

The privacy concern is the association of the *hard-to-change* unique MAC 
address with its GPS location. 

These two critical pieces of metadata are *uploaded* to the Google Public 
Database by poorly configured Android devices, whether or not you put 
"_nomac" on the SSID.

>> However, you must realize that the Google Public Database contains
>> *more* than the SSID! It contains the *unique* BSSID associated with
>> that SSID, and furthermore, it contains the Signal Strength of that
>> access point at a specific GPS location of the poorly configured
>> Android device that is near that access point.
>>
>> Anyone who doesn't *understand* that paragraph above can't possibly 
>> understand the topic of this thread - so it's critical that the paragraph 
>> above be *understood*.
> 
> That "paragraph above" means absolutely nothing until one understands
> that even in a "properly configured" phone user level code could be
> gathering the same information (or more) and sending it to agents
> unknown. 

Bruce .... you're trying to argue that the world contains a lot of 
parameters, and nobody (not even me!) is disagreeing with you.

You may as well tell me that every radio has a MAC address or that every 
radio has an antenna or that every computer on the net has an IP address or 
that the BSSID is in every packet, etc.

Nobody is disputing what you're saying - but what you're saying has 
*nothing* whatsoever to do with the topic at hand!

The topic at hand is *only* about the BSSIDs that are *uploaded* to the 
Google Public Database by poorly configured Android devices.

The two related questions are:
a. Under what circumstances is your phone's BSSID uploaded to the Google 
Public Database?
b. How would an attacker *exploit* that public database to track the 
*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic 
here that "I" am trying to find out more about.

>>> A wifi access point consists of one or more radios to create a WAN.
>>> Each radio is a BSS with a BSSID, which is also known as a MAC.  Each
>>> network device/radio has (by design, but not always in fact) a unique
>>> value for the MAC.
>>
>> I agree. Specifically, if an iOS or ANdroid cellphone is acting as an 
>> access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
>> a. The cellphone AP SSID
>> b. The cellphone AP BSSID
>>
>> What you must understand to understand the question, is that poorly 
>> configured Android devices will *send* to Google not only that information 
>> above, but *more* information!
>>
>> Poorly configured Android devices will send to Google:
>> a. Your cellphone AP SSID
>> b. Your cellphone AP BSSID (aka MAC address)
>> c. Your AP signal strength seen by the poorly configured Android cellphone
>> d. The GPS location of the poorly configured Android cellpone
> 
> As stated above, poorly configured is not the problem, and Google might
> not be the only recipient.

The two related questions are:
a. Under what circumstances is your phone's BSSID uploaded to the Google 
Public Database?
b. How would an attacker *exploit* that public database to track the 
*location* of the phone? 

If you want a *different* topic, then just say so - but *that* is the topic 
here that "I" am trying to find out more about.


>>> A device wishing to connect to a wifi access point looks for a
>>> broadcast wifi packet with a particular SSID in the data field of the
>>> packet.  The header to the packet contains the BSSID/MAC of the
>>> access point in source field.  To connect to the access point the
>>> device sends a packet back to the sender of the broadcast by putting
>>> the access point's BSSID in the destination field of the packet and
>>> its own MAC in the source field.  The rest of the connection protocol
>>> is left as an exercise for the reader.
>>
>> This part is understood that the BSSID of the 5Ghz and 2.4GHz radios
>> in both iOS and Android devices is sent in the clear in packets
>> whenever those cellphones connect to an access point.
>>
>> But I'm not talking about that.
>>
>> I'm only talking about when an iOS or Android cellphone has the
>> following four bits of information *sent* to the Google database by
>> poorly configured
>> Android devices:
>> a. Your cellphone AP SSID
>> b. Your cellphone AP BSSID (aka MAC address)
>> c. Your AP signal strength seen by the poorly configured Android
>>     cellphone
>> d. The GPS location of the poorly configured Android cellpone
> 
> Get off this poorly configured fixation you have.  A perfect config-
> uration with any amount of user-level programs has potentially the same
> nasty possibilities.

The two related questions are:
a. Under what circumstances is your phone's BSSID uploaded to the Google 
Public Database?
b. How would an attacker *exploit* that public database to track the 
*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic 
here that "I" am trying to find out more about.

[toc] | [prev] | [next] | [standalone]

#38836

I assume you're referring to things like:

http://arstechnica.com/information-technology/2014/11/where-have-you-been-your-smartphones-wi-fi-is-telling-everyone/

http://www.zdnet.com/article/how-google-and-everyone-else-gets-wi-fi-location-data/

http://www.theregister.co.uk/2011/04/22/google_android_privacy_concerns/

and the like.  (I Googled for "Android, cellphone, collecting router
SSID, location, privacy" and got those and many other articles.)

There's two broad categories: whether there are risks to the person
carrying the cellphone and whether there are risks to the people around
them operating a wireless router.

It looks to me like you are NOT talking about risks to the wireless
router owners.  You're asking about locating a cellphone owner, so I'll
focus on that.

There were several ideas floating around a few years ago, as I recall.

* In NYC skyscrapers and the like, there are situations where knowing
  more than just the street address might be useful.  If the building
  has wireless routers, and if their locations are known, then it
  becomes possible to estimate which floor one is on from which router
  signals one hears and how strongly.

* IIRC (and I might not be), there was talk of whether it would be
  practical to gradually replace expensive cellphone towers with large
  numbers of cheap WiFi access points for cellphones (femto access
  points, I think I've heard them called).  Doing so would also help
  pinpoint the cellphone's location more accurately than is possible
  with the big cellphone towers, since the range of any particular
  femto-cell would be small.  Cellphones able to switch between
  cellphone mode and WiFi mode on the fly, or even just use WiFi for
  data, might also reduce TelCo-metered usage.

You speak about getting a location via Google even though you enter a
fake signal strength.  I don't see how that can work.  If you say a
signal is really strong, that indicates you're close.  If you say the
signal is weak, you're further away.  Choose any combination of places
around the world and make up whatever signal strengths you like, and you
probably can get a result anywhere on Earth, even if those numbers are
impossible in practice.

If I have a wireless router in Google's database, and you submit
something that says you hear my router (at all), I would think it'll say
you're somewhere near me, even if you aren't.  As you enter more
numbers, you can triangulate a position, but if you're making up
numbers, the answers wouldn't be meaningful.


A few specific points:

Horace Algier <horatio@horatio.net> writes:
> "if" your cellphone does broadcast an
> SSID, then your cellphone *can* be tracked.

(B)SSID aside, all cellphones are tracked to the level of "nearest
cellphone tower" whenever they're on.  If they're within range of more
than one tower, the range of possible locations is greatly reduced.

> However, even if the router's MAC address could be cloned (it can't,
> at least not without desoldering and other heroic actions),

Huh?  The wireless routers I've configured allow changing of their MAC
addresses, often during the initial setup/configuration.  (See DD-WRT,
ifconfig options wlanbssid #id and wlanaddr #addr (the latter sets the
WLAN local MAC address).  Regarding some other options, 'man ifconfig'
says "Note that this feature does not significantly enhance security as
MAC address spoofing is easy to do.")

There once was a company that manufactured Ethernet devices that all had
the same MAC address.  When customers discovered that, they got upset.
The manufacturer changed to providing unique addresses (I think).  While
customers could change the MAC address, they didn't have enough
information to ensure the address they chose was unique, as the
manufacturers do.

OTOH, if you meant cellphone instead of router, I'd mostly agree:
cellphone handsets are intended to have unique IDs.  However, I'm not
sure whether that's the same as the MAC address the cellphone would use
to connect to a WiFi hotspot (but maybe it is).

Whether it's changeable or not doesn't really matter: once a router has
been configured, its MAC addresses are rarely changed (short of
replacing the router), so once SSID X has been heard transmitting at
location Y, the X,Y pair should be valid for some time.  [I can also
think of ways to handle the case of duplicate MAC addresses (except when
the duplicates are operating so close to each other that one can be in
both of their signal areas at the same time).]

Fortunately, they're irrelevant to the question of whether Google's
database can be used by someone remotely to locate a cellphone user in
the absence of actual signal information.  I don't see an obvious way to
do that.  There's also the method of accessing the cellphone's own
recorded location history file (see articles), but that doesn't involve
Google.

Have I completely missed the point?
 -WBE

[toc] | [prev] | [next] | [standalone]

#38877

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> I assume you're referring to things like:
> http://arstechnica.com/information-technology/2014/11/where-have-you-been-your-smartphones-wi-fi-is-telling-everyone/
> http://www.zdnet.com/article/how-google-and-everyone-else-gets-wi-fi-location-data/
> http://www.theregister.co.uk/2011/04/22/google_android_privacy_concerns/

THANK YOU WINSTON FOR UNDERSTANDING WHAT THIS THREAD IS ABOUT!
(sorry for shouting)
I'm just so happy that not only Jeff, but someone else also understands
what this thread is asking!

Also, thank you Winston for looking up the issue so that we could talk
about the topic of the thread.

Yes. You are correct.
This is a problem on both Android & iOS phones.

Looking at each of the three articles, here's a quick summary review:

1. Where’ve you been? Your smartphone’s Wi-Fi is telling everyone.
Every time you use Google or Apple mobile location services, you’re not
just telling the services where you are. You’re also shouting many of the
places you’ve been to anyone who happens to be listening around you—at
least if you follow Google’s and Apple’s advice and turn on Wi-Fi for
improved accuracy.

2. How Google--and everyone else--gets Wi-Fi location data
Google doesn't use StreetView cars to pick up Wi-Fi location data any more.
They use your smartphones and tablets instead.
Eitan Bencuya, a Google spokesperson, tells me that Google no longer uses
StreetView cars to collect location information. So, how does Google
collect Wi-Fi location data? They use you.

Or, to be more exact, they use your Android phone or tablet. But, it's not
just Google. Apple and Microsoft do the same thing with their smartphones
and tablets. 

3. Google location tracking can invade privacy, hackers say
Unique IDs + router addresses = potential abuse
In October, Google pledged to stop using its world-roving Street View
vehicles to collect Wi-Fi data and said it instead would rely on Android
handsets to get the information. When phones running the Google OS detect
any wireless network, they beam its MAC address, signal strength and GPS
coordinates to Google servers, along with the unique ID of the handset.

Unfortunately, the lookup that was at that web site says Google disabled
the web site (but the lookup still works from the Google API):
http://samy.pl/androidmap/

Notice though, that this web site says:
  "android map exposes the data that Google has been collecting from
virtually all Android devices and street view cars, using them essentially
as global wardriving machines. You can use this tool to accurately locate
virtually any router in the world, as well as position *iPhones* and
*Android phones.*

So notice that all I'm asking is for more information about that last
sentence:
 -  You can use [query the Google Public Database] to accurately locate
...the position of *iPhones* and *Android phones.*

[toc] | [prev] | [next] | [standalone]

#38878

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> There's two broad categories: whether there are risks to the person
> carrying the cellphone and whether there are risks to the people around
> them operating a wireless router.

While you're correct, the only risk I'm looking at is how to *abuse* the 
Google Public API database in order to *track* the *current* location of a 
cellphone whose BSSID (aka MAC address is known to you) and where you also 
know the BSSID of the AP of, say, the local Starbucks.

The Google API (as a "security" measure) requires *two* MAC addresses 
before it will spit out the GPS location of *both*.

So, if you *think* the cellphone is at Starbucks, and if you know both MAC 
addresses, you can *prove* the cellphone is at Starbucks.

That's all I'm asking about.

When does a cellphone's MAC address & Location & SSID & GPS coordinates get 
captured into the Google Public Database?

That is the question!

[toc] | [prev] | [next] | [standalone]

#38889

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> OTOH, if you meant cellphone instead of router, I'd mostly agree:
> cellphone handsets are intended to have unique IDs.  However, I'm not
> sure whether that's the same as the MAC address the cellphone would use
> to connect to a WiFi hotspot (but maybe it is).

I am only talking about cellphones, and their MAC addresses of their 2.4GHz
and 5GHz radios, but in the case of cloning, nobody understands what Jeff
Liebermann understands.

The MAC address you *want* to clone to keep it out of Google's database
can't be easily cloned. Jeff and I am sure you can go through heroics, but
it would be easier to buy a dozen routers a year and just replace them each
month than it would be to try to change the MAC address of the radio that
is broadcasting the SSID.

[toc] | [prev] | [next] | [standalone]

#38890

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> Huh?  The wireless routers I've configured allow changing of their MAC
> addresses, often during the initial setup/configuration.

Everyone on the planet knows that you can clone *one of* the router's MAC
addresses. But that's the *wrong* MAC address.

Look in the record for alt.internet.wireless for example:
 http://tinyurl.com/alt-internet-wireless 

I think this is the thread, but it doesn't matter because you can't clone
the MAC address you *want* to clone for *this* purpose!
https://groups.google.com/forum/#!topic/alt.internet.wireless/-PK03bCEheM[1-25]

Here is what Jeff Liebermann said in that thread:
Cloning the router's mac address can't work.
Using the router feature of MAC address cloning or
changing only changed the MAC address for the WAN (internet) port.
That's useful for the few remaining ISP's that authenticate by MAC
address, but not really a good privacy measure.  The MAC addresses for
the LAN side, including the wireless, remains unchanged.  Since Google
wants the LAN MAC address for their directory of wi-fi devices, you're
stuck with the MAC address delivered by your wireless router vendor.

The only way I can currently think of changing the wi-fi MAC address
is to plug a wireless card into a PC or SBC (single board computah),
set it up to act as an access point, and change the MAC address in
Linux.  
<https://wiki.archlinux.org/index.php/software_access_point>
I haven't tried this. 

[toc] | [prev] | [next] | [standalone]

#38896

On Sat, 17 Sep 2016 01:59:36 -0000 (UTC), Horace Algier
<horatio@horatio.net> wrote:

>On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:
>
>> Huh?  The wireless routers I've configured allow changing of their MAC
>> addresses, often during the initial setup/configuration.
>
>Everyone on the planet knows that you can clone *one of* the router's MAC
>addresses. But that's the *wrong* MAC address.
>
>Look in the record for alt.internet.wireless for example:
> http://tinyurl.com/alt-internet-wireless 
>
>I think this is the thread, but it doesn't matter because you can't clone
>the MAC address you *want* to clone for *this* purpose!
>https://groups.google.com/forum/#!topic/alt.internet.wireless/-PK03bCEheM[1-25]
>
>Here is what Jeff Liebermann said in that thread:
>Cloning the router's mac address can't work.
>Using the router feature of MAC address cloning or
>changing only changed the MAC address for the WAN (internet) port.

Notice that I said router, not client radio, access point, or some
unspecified software running on your unspecified smartphone.  The
"hardware clone" feature found in consumer router firmware only
changes the WAN port MAC address.  The LAN ports (including Wi-Fi) are
unaccessible by mere mortals.  Like a PC or laptop allows anyone to
change the MAC address of its ethernet port or wireless device, you
can change the MAC address of a software based smartphone access point
if you have root access.

However, that's for a normal router that hasn't been hacked or has had
the firmware replaced.  If you have root and shell access, you can
just use ifconfig to change the MAC address of any addressable port.
For example, in DD-WRT:
  ifconfig wlan0 down
  ifconfig wlan0 hw ether 11:22:33:44:55:66
  ifconfig wlan0 up

That's also for a normal non-rooted smartphone.  If you root it, you
can again use ifconfig to change the MAC address of any port.
<http://www.gohacking.com/spoof-mac-address-on-android-phones/>

If you want to drive Google partly nuts, just change your smartphone
wi-fi MAC address at irregular intervals.  That won't stop them from
tracking you by some of the other stuff they are harvesting from your
phone, but it's a good start.

Gotta stop typing for a day.  I tried to start a chain saw today and
now right wrist is swollen.

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web