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

The Nordstrom example is interesting, but it's not the mechanism that I'm looking at in this question.

In *this* question, what's only germane is what conditions an iOS or Android device is put into the Google Public Database by poorly configured Android devices in its vicinity.

So far we've confirmed what I already knew, which is that any iOS or Android cellphone acting as an Access Point, will already be in the Google Public Database because it will have encounted numerous poorly configured Android devices which tell Google every day all the SSID/MAC/SS & GPS Location information of *every* access point they encounter (encrypted or otherwise).

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?

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.

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.

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!

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*.

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

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

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:

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).

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

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.

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

I tripped over a broken concrete walkway at a customers while doing my best to not pay attention. I came down on my knees and wrists. Some skin missing from the knees, stiff knee muscles, and sprained wrists. I was recovered enough yesterday to get talked into helping move a hot tub. Now, I feel worse. The wrists are sufficiently healed that I can now function without a pain killer. I think I'll live.

Not exactly. 802.11 does nothing more than gift wrap ethernet packets which in turn carry TCP/IP packets. Just as ethernet needs to know the source and destination MAC addresses to make it through a switch (also known as a multiport bridge), so does 802.11 packets need to know the source and destination MAC addresses of the wireless devices involved in the wireless network. In other words, 802.11 is nothing more than ethernet done without wires. A better example of the similarity is a "wireless switch" which is literally a smart ethernet switch that uses wireless access points to connect to computers, printers, and such.

The cell phone is playing access point and bridge. The access point is easy. It encapsulated ethernet packets inside 802.11 packets and sends them via 2.4GHz to a wireless client. The bridging is a mess. You have the: Wireless client(s) talking to cell phone. The wireless client radio is a bridge between ethernet and wi-fi. The soft access point in the cell phone bridges wi-fi to the data modem in the cell phone, which is another bridge. Every hop along the way is bridging, usually with MAC addresses involved.

That wasn't your original question. However, I can easily answer that. Google got into trouble because they were also sniffing and storing the Wi-Fi payload. Google believes that it is entitled to collect any data that is does not constitute user information, which is loosly known as metadata. Worst case is that it might not record your credit card number sniffed during drive by, but might record the time and date when a credit card was used. Less extreme might be Google recording when and from whom something was purchased, but not what was purchased. The dividing line between acceptable data collection and the invasion of privacy is a moving target. I had hoped that the courts would have settled the matter by now, but that's hardly the case.

"We want you to understand what data we collect and use." Hmmm... doesn't mention wireless sniffing because Google has announced that it no longer collects wifi data: Note that metadata and data are quite different.

Gotta run. I'll attack the rest later (time permitting). I can explain how wi-fi works, but I can't explain every detail of how Google collects wireless data. It would be helpful if you actually asked a question. Tacking a question mark on an assertion is difficult to decode.

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.

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:

improved accuracy.

1. 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.

1. 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):

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.*

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!

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.

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:

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!

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. I haven't tried this.

I'm *not* asking about cellphone triangulation. That's totally different.

Google added the need for the *second* BSSID for security reasons, so that you'd actually have to know *both* BSSIDs in order to do a lookup.

Of course, if you're *at* the location, you can *easily* obtain two BSSIDs and their relative signal strength, so that's why Google gives any app that asks, the GPS coordinates if you give the Google database three things:

1. BSSID 1
2. BSSID 2
3. Signal Strength

Again, if you are actually at that point, then it would be trivial for you to have the BSSIDs, and the signal strength.

However, if you're faking it, then you have to fake the signal strength.

The way to fake the signal strength is to give both BSSIDs the same (or similar) signal strength. (That means they're together.)

That way, you're talling Google that *you see* both access points together.

One of two things will happen, if I understand the "system" (and assuming the hubby's ios or Android cellphone is one of the access points and the other access point is the Starbucks nearest his girlfriend):

a. If the two access points *are* together, then Google will gladly report back the GPS coordinates. BINGO! That's your test that hubby is at the Starbucks over by his girlfriend's home!

b. If the two access points are *not* together, then Google will NOT report back the GPS coordinates.

Pretty simple if you ask me. This only works though, if the iOS or Android cellphone is being betrayed by other poorly configured Android devices.

So that's why I ask under what circumstances does an iOS or Android cellphone get its SSID/BSSID/SS and GPS position reported to the Google database?

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:

Which refers to the canonical Geolocation API from Google:

Notice all you need is:

1. BSSID 1
2. BSSID 2
3. Signal Strength

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.

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.

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.

Hi Jeff, I do remember almost everything that you've ever said, that I understood.

And, while most people *think* you can clone the LAN ports "of the router", it's not so easy (as you are explaining). Basically, for "our" purposes, changing the WiFi (2.4GHz or 5GHz) Access Point MAC address can't easily be done on a typical home router even though you are "admin" on that router.

I have no idea if *that* restriction applies to a *cell phone* so I will read on ...

Ooooooh.... this is new. Interesting too... Please do go on...

Ok. Fair enough. So you're saying that the Access Point (5Ghz and 2.4GHz) MAC address is not easy to change on a router that doesn't have the firmware replaced with custom softwqare.

I do this on Linux daily (I have a script) - so - are you saying that if you had root access to an iOS or Android cellhone or if you have "special" more-than-root access on a router, that you *can* easily change the MAC address that is associated with the cellphone's SSID access point?

OK. SO is this the summary?

1. ROUTER a. You have root access on the router, but you still can't change the Access Point MAC address on most consumer router firmware b. However, if you load *special* router firmware, you *can* change the Access Point MAC address If you want to drive Google partly nuts, just change your smartphone

We already know there is one way to prevent them from *harvesting* an access point MAC address - and there is another (different) way to prevent Google from *saving* your harvested access point MAC address - and there is yet another way to (do something) with respect to Microsoft harvesting of your access point MAC address:

1. If you *hide* the access point SSID broadcast, poorly configured Android devices will *not* send your access point MAC address to Google.
2. If you append *_nomac* to the end of your access point SSID, then Google promises to remove your access point from their database.
3. If you insert "_optout", then Microsoft will leave you alone (somehow)

Ouch. I use a chain saw a *lot* as I create paths that go for miles and miles and miles, so I have to cut a lot of dead wood to clear it away. My Stihl is pretty good about starting up, but still - it's a pull on the wrist.

Please heal. We need your acumen on her, as there's precious little to go around.

Looking at the reference for spoofing the MAC on Android & iOS, it seems these are the requirements for Spoofing the Access Point MAC Address: a. Rooted Android Phone b. BusyBox app installed on your phone c. Once BusyBox is installed, you need to install Terminal app

Here's how to do it manually (according to that reference): $ su $ busybox iplink show eth0 (This will show your current MAC address, just for your confirmation) $ busybox ifconfig eth0 hw ether DE:AD:BE:EF:CA:FE

You have now spoofed your MAC address successfully. To check for the change enter the following command again: $ busybox iplink show eth0

Here are two apps that do it for you (according to Google Play):

Wifi Mac Changer by Osama Abukmail

MacMan by Maxters

Do you think the process to spoof the Access Point MAC address is similar for jailbroken iOS phones?

Googling, it seems the iOS process is (far) more complex than is Android for spoofing the MAC address of the access point (because Apple keeps breaking it with every new OS release, apparently).

So, in essence, you can't spoof the access point MAC address on any recent iOS version...

But, if you try, these are the minimum requirements: a. A jailbroken iOS device b. MobileTerminal package or any SSH terminal to execute commands on the iOS device c. developer-cmds & network-cmds packages (available on Cydia).

But the problem is that Apple prevents you from doing this (as Apple prevents you from doing most things you can do on all other platforms).

Details here:

Where the author concludes: "So, my best-mac-tip when it comes to spoofing your MAC address on an iOS

customisation) is just one of the many reasons why I use Android phones and tablets."

apple doesn't break stuff with every new release.

nevertheless, ios has had mac address randomization built into the os since ios 8, which occurs in some situations (it can't be all for obvious reasons that you probably don't understand).

you've been told this before and you continue to ignore it so you can lie.

It does. I have 2 apple machines myself. And I know several apple users who are afraid of updating the OS. Because they have made the experience that all too often something does not work anymore

it doesn't. i have more than 2 and the issues are both minor and rare. nothing is perfect so it will never be zero.

the above troll is referring to functionality offered via jailbreaking, which is not supported in the first place, so it's no surprise it changes.

meanwhile, look no further than microsoft's anniversary update for breaking things.

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.

Again, here I was attepting to lay a background.

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

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.

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.

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.

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.

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.

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.

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

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.

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

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.

Or maybe even "Angry Birds" does this too!

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 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. 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".

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

Huh?

You might want to look into this then.

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 .

Wow. Sorry about that fall. I saw your pictures, and you're in decent shape for an old guy like me. (You were wearing army stuff from the army-navy store.)

I hope you heal soon.

Jeff - since there is a "soft access point" on both iOS and Android phones, does that mean that this soft AP SSID/BSSID/SS & GPS location is sent to Google by all those poorly configured Android devices?

Jeff - you're apparently talking about the Google vehicle that drives along all the roads in the United States. I'm *not* talking about that WiFi collection vehicle.

I'm talking about the fact that almost all Android cellphones are poorly configured in that *they* are collecting the SSID/BSSID/SS of all access points, and sending that, plus the current GPS location to Google many times a day.

It's already discussed on *many* web sites. Winston supplied three of them already:

So we're *only* talking about what data the poorly configured Android cellphones provide to Google many times a day for all the iOS and Android phones it encounters.

That's for the car. We're talking about poorly configured Android cellphones collecting this data. See the URLs from Winston for details. They're titled:

1. How Google--and everyone else--gets Wi-Fi location data
2. Google location tracking can invade privacy

Hi Jeff,

I realize you always try to help, and that you provide details, which is expensive in costs of energy and time.

I read *everything* you write, but I don't always understand everything you write.

However, the *only* question that matters is under what circumstances is an iOS or Android cellphone's SSID/BSSID/SS and GPS location *reported* to Google databases by poorly configured Android cellphones.

I *think* the answer is that this happens *only* when the iOS or Android cellphone is configured to act as an *access point*.

I'm just trying to confirm that setting up an iOS or Android phone as an access point is the *only* situation where an iOS or Android cellphone is reported to the Google API that collects the SSID, BSSID, Signal Strength, and GPS location from a nearby poorly configured Android device.