Magic of Chromecast under the hood
Tags: Wireshark, Chromecast, Networking, Wireless, Packet Capture

Humans sometimes are lazy enough to take things for granted, and their curiosity takes a toll because of it. We even forget our over-enthusiasm and curiosity as a child who wants to know it all. But there always comes a time or event which makes you think, “How exactly this stuff work?”

The same happened to me too. It was a fine day, me and my husband sat down to watch a movie. We were trying to cast Netflix to our TV and nothing was happening. What was wrong? The wireless engineer in me became curious to figure out the issue, to know how the Chromecast works, how we cast to the TV. How this magic happens!!!

And then, I took my laptop, started a packet capture(my best buddy :)), and started looking into the thousands of packets to resolve the mystery.

So here it is all about Chromecast, its communication with other devices, various protocols involved.

Chromecast, I don’t think it needs any introduction. Everyone is aware of what Chromecast is, may have been using it, or might have thought of buying it after a friend’s suggestion. This small magical device lets you watch videos, listen to music, play games, and use other types of apps from the Internet on your TV.

Coming to the part on how it works, so it all starts when you turn on your TV. The Chromecast powers up and try to connect with the Wi-Fi.

It connects to the Wi-Fi in a similar way how a wireless device connects with Wi-Fi using 802.11 Protocol.

Below is the snapshot of packet capture that shows the Authentication and Associations packets between the access point and the Google Chromecast, followed by a 4-way key exchange. The Auth method used is WPA2/PSK.

Authentication process with WiFi

Now every device that needs to do communication over the Internet need an identity, yes you guessed it right, an IP address. Next, the Chromecast communicates with the DHCP server and gets an IP address.

My Chromecast gets an IP address of 192.168.1.2.

DHCP Process

Now the Chromecast has an IP address. It cannot sit idle, it wants to go out and see around the world. It tries to find the way out. It tries to find the physical address of the default gateway.

ARP for Gateway

Now the mother of Chromecast or his creator would have provided him some URLs to reach out once he is awake and has a way out to the Internet.

There are a few URLs for which the Chromecast tried to resolve DNS.

DNS requests to various google URLs

connectivitycheck.gstatic.com: It is the check for internet connectivity after joining a WiFi network. Every Android device requests https://connectivitycheck.gstatic.com/generate_204 after connecting to a wireless network.

Check the below page for more information:

https://malv.in/posts/2018-11-08-self-hosting-the-wifi-connectivity-check-for-android.html

2. time.google.com : It is a google public NTP server. Chromecast uses the NTP protocol after it rebooted to get the current time through an NTP server.

Chromecast use SSDP and DIAL protocols for device discovery, NTP for time synchronization, TLS for encrypted communications.

Below are more URLs that Chromecast tried to resolve DNS. I tried to google to check what these URLs do or why they are used for but did not find any concrete answer.

clients1.google.com

tools.google.com

After resolving DNS, it established a TCP connection with these endpoints.

Chromecast uses TLSv1.2 for communicating with TLS capable servers. For example, Chromecast communicates over TLSv1.2 while downloading an image to display during idle. After getting the IP address of the content server from Google DNS, Chromecast and the content server does the 3-way TCP Handshake, which is followed by Client Hello and Server Hello TLS messages.

Below is the example for connectivitycheck.gstatic.com.

TCP connection

Till now, it was all about how Chromecast connects with WiFi and how it communicates with the Internet and establish TCP connections with the google endpoints.

After you power on your TV, you open Netflix or youtube sees that small cast button. Once you click on that button, it shows you the name of your Chromecast that you would have configured while setting up the Chromecast device, and Ta-da, the Chromecast is in your service, and now you can just cast anything on the TV.

Let’s see the networking behind this.

Two things that work behind the curtain are Google cast SDK and Google Cast Protocol.

The Google cast SDK : Check this link on detailed information https://developers.google.com/cast

2. Google cast protocol: It is used to discover the receiver device.

Chromecast uses a simple multicast protocol for Discovery and Launch that enables users to mirror their devices on a second screen.

mDNS packets

Multicast DNS(mDNS) — The Chromecast says to the router — please send this message to all interested devices on the network. You open the app on your phone and tells the router, “I’m interested in messages about the Chromecast”. When the router receives a message from the Chromecast — it goes “I have 5 devices that are interested in these messages” and sends the message to all the devices.

Source — https://www.reddit.com/r/Chromecast/comments/4da89i/how_does_chromecast_work/

192.168.1.2 is the IP for the Chromecast device, and 192.168.1.3 is my mobile device. The mDNS packets can be seen from my mobile also.

mDNS packets from the mobile device

SSDP protocol: Simple Service Discovery Protocol is a discovery protocol used to determine what services are available on a network.

Chromecast and devices on the same network with Chromecast communicates via DIAL protocol to discover each other. Both devices send multicast SSDP messages over UDP to IP address 239.255.255.250 on port 1900. M-SEARCH *HTTP/1.1 packets are multicasted by clients for Chromecast discovery, while the Chromecast device sends NOTIFY *HTTP/1.1 packets to announce the IP address and port it is listening to and the location of its device description XML ﬁle. According to NOTIFY * packets sent by Chromecast, device description ﬁle is found at http://local-chromecast-ip-address:8008/ssdp/device-desc.xml.

SSDP packets

YouTube app in Android tablet has a cast to Chromecast button enabled if the mobile device has previously discovered a Chromecast device in the same network. Once tapped, the tablet would stop showing the video on the small screen and start streaming the YouTube video to the Chromecast attached larger screen. The tablet device becomes a remote control. In this setting, the control packets such as play, stop, pause, etc. are sent through clear-text over HTTP from tablets to YouTube servers. The video control packets are sent from the mobile remote device to YouTube servers and video is streamed directly to the Chromecast. When looked closer to the control packets; they use HTTP POST, HTTP GET methods to control the video played on Chromecast attached screen.

Source — https://www.researchgate.net/publication/283804043_A_closer_look_into_privacy_and_security_of_Chromecast_multimedia_cloud_communications

Below is the example of a youtube HTTP request

This is the journey of Chromecast from the time it powers up to the time you start watching your favorite video or movie on your TV screen. We saw how it connects with the Wifi, what protocols are involved, how devices discover each other, and how you can cast on the TV from your device.