Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faster Chromecast network identification #4

Open
altf4 opened this issue Jul 16, 2014 · 9 comments
Open

Faster Chromecast network identification #4

altf4 opened this issue Jul 16, 2014 · 9 comments

Comments

@altf4
Copy link

altf4 commented Jul 16, 2014

The Chromecast Android app is really fast at identifying when a Chromecast network is nearby. Even when you're not connected to the same network. Specifically, if your phone is connected to Wi-Fi A, and the Chromecast is broadcasting Wi-Fi B, the Android app (which is connected to Wi-Fi A) picks up on there being a Chromecast nearby really quickly. And you never lose connectivity to the Wi-Fi A.

The Rickmote currently identifies Chromecasts by connecting to all Open networks, and then doing an HTTP GET for "http://192.168.255.249:8008/setup/eureka_info". If we get a 200 back, we can be pretty sure it's a Chromecast network. But this is slow since you have to disconnect from the Wi-Fi you're on, reconnect out to a new network, DHCP, and then HTTP GET. And you have to do it all one at a time. Very slow.

What is the Android app doing, and how can we copy it?

@bramp
Copy link

bramp commented Jul 22, 2014

I spent some time decompiling the Chromecast.apk file. It seems to simply search for all APs, and checks if the BSSID starts with "00:1A:11:FF:" or "FA:8F:CA:".

There is also a reference to a "SSDP scan". I don't know what that is, but I suspect it something similar to the GET mention above.

Finally I don't know if/how it's used but I found the Strings "Chromecast", "Chromekey", "Eureka Dongle". I don't know in what context they are used.

@altf4
Copy link
Author

altf4 commented Jul 22, 2014

Nice work!

That's exactly what I suspected the Chromecast app was doing. But I never got the chance to test it. Awesome, that should make for a MUCH faster time for identification. I'll code it up and test it out first thing.

SSDP is part of the DIAL spec that clients use to discover Chromecasts on their network. (As opposed to discovering Chromecast APs) It's a UDP protocol. If you look at the rickmote.py, it sends a UDP message that sorta looks like HTTP to port 1900. That's SSDP.

@altf4
Copy link
Author

altf4 commented Jul 25, 2014

Okay, I understand why I was confused about this issue earlier. Chromecasts have two Wi-Fi devices internally. One is an AP and always has a MAC address of "00:1A:11:FF:" or "FA:8F:CA:", the other is a managed mode device with a wide array of MAC addresses.

The second one is what you see when you view the MAC of your Chromecast in the android app UI. That explains why I never saw any discernible pattern to the vendor IDs.

@bramp
Copy link

bramp commented Jul 25, 2014

hehe yes, I noticed that weirdness as well.

@jag34
Copy link

jag34 commented Sep 16, 2014

I've been doing some testing on recognizing Chromecast devices nearby using scapy. Of course, this is much slower but it can properly identify nearby Chromecasts effectively by keying off of the manufacturer, which seems to be "Azureware". I have noticed that upon deauthing, the management WiFi has a different MAC with an unrecognized manufacturer, I googled the first 3 octects and came with nothing, but indeed matches the "FA:8F:CA:" that you guys have described.

You could probably identify nearby chromecasts this way, but this might not improve speed of discovery.

@altf4
Copy link
Author

altf4 commented Sep 23, 2014

I haven't yet noticed any pattern or list of MAC prefixes for the client WiFi that the Chromecast uses. The AP always has a MAC address of "00:1A:11:FF:" or "FA:8F:CA:". But I've seen the client have lots of different vendor IDs.

If there WERE a list of known vendor IDs, that would be really useful. Since then we might not need to de-auth at all in order to identify chromecasts. So keep an eye out for that.

@jag34
Copy link

jag34 commented Sep 24, 2014

It looks like iFixit confirms that they're using a AzureWave chipset for their wireless stuff. I'm sure all american Chromecasts will have the same components. The AP might just be a software access point using the same chip but a spoofed mac address, which would be why there's no manufacturer associated to it.

I'm sure other things also have a chip made by AzureWave, but if they are within a wireless range you just won't be able to see an open network after deauthing.

@Monchos
Copy link

Monchos commented Aug 20, 2015

If you don't want to see a hidden network with a MAC address FA:8F:CA trailing your main WiFi network, then turn off guest mode on all of your Chromecasts or do a factory reset and set them up again without the guest mode.

@altf4
Copy link
Author

altf4 commented Aug 20, 2015

The "guest mode" thing is pretty new to Chromecasts. This Issue was made before that functionality existed, actually.

Removing guest mode doesn't make your Chromecast immune to Rickrolling, unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants