-
Notifications
You must be signed in to change notification settings - Fork 100
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
How does Device Authentication work ? #2
Comments
The culprit is the The Chromecast uses 2 certificates. The first one is used for the TLS connection, is self-signed and expires every 24 hours (let's call it the peer certificate). The second one is used to validate the first in the device authentication process (let's call it the platform certificate). I added a few tools in the The process seems to go as follows.
Long story short, I'm not an expert in cryptography but it seems that without the platform certificate private key used to produce the signature, not much can be done. |
I stumbled across this repo. It seems to have tools related to the certs on the chromecast. Thought it migth be of some help. https://github.com/EiNSTeiN-/chromecast-widevine-tools |
Looks good indeed. Thanks a lot ! |
Are there some updates on this? :) |
Nothing yet. I don't have time nor interest in searching this direction but I'll help if I can. |
Am I rigth that the only way to get authentiation is work is buying a chromecast and root it? |
I can't say for sure. A first step would be understanding the auth scheme and looking at the chromium source code. |
Somme guys managed to make it work in a Python project: https://github.com/dz0ny/leapcast |
Hmm, where exactly is the code that does it ? |
I think |
I do not think, that this is related to chromecast v2 protocol; |
I think @leo-labs is right, it doesn't look like the same process at all. Probably only relevant to the DIAL protocol. |
The chromecast protocol is new to me so sorry if this is a dummy question :). |
This looks like it should work in principle, but in effect I fear the Chrome browser will be too sensitive. During discovery the browser does an mDNS lookup and immediately connects to and authenticates the devices it found. I'm not sure two devices with the same credentials will be accepted. I may even have tried this and failed, can't remember exactly. I may have messed something up during my tests, too. |
Did someone just ask google to get an certificate for custom applications? Google seems to allow chromecast devices from other manufacturers, like smartTV's or speakers, for example this: http://www.xperiablog.net/2015/01/07/sony-announces-speakers-with-google-cast-for-audio-support/ Maybe this is not as problematic as we think? |
I doubt they took the burden of creating an auth system only to deliver free keys later. But well, you should ask ! |
I've done some looking into this, and noticed that the AuthResponse structure of cast_channel.proto is slightly wrong. There is an additional repeated field at index 3 that contains the CA certificates that's used for verifying the client_auth_certificate on the client-side (on Android it's done through CertPathValidator). |
Interesting. I have no immediate interest in pursuing that but I'll gladly accept PRs. |
Checking the last version of the sources it is clear that there are several CAs and that now that field is repeated as a CA chain can be sent. So to make all this work we need a device cert signed with one of those CAs or use a Chrome client that skips that validation. I am no aware of anyone but it should be simple to create one. Probably there is one CA cert for every vendor, so they have to pay the fees to be included in the SDK and future ChromeCast clients. |
Has anyone tried to install this XPosed module to be able to skip Device Authentication? https://github.com/HomerSp/XposedCastClientFix (Source: http://forum.xda-developers.com/hardware-hacking/chromecast/app-cast-receiver-app-android-t2900726) |
@Afterster Indeed that appears to be the case. Simplest course of action would be to expose public internet service providing signatures via libGtvCa (ie everyone would essentialy see the very same device) running on a rooted dongle. This is both simplest implementation and works against the worst case when signatures are provided by DRM hardware in the dongle (ie extracting root key will be very difficult). EDIT: According to XDA, v2 proto seems to use widevine hardware DRM for key provisioning. Hey google, you promised to not be evil :/ |
@JumpLink I pushed your qquestion into the chromecast help forum. Maybe this is the right forum. https://productforums.google.com/forum/#!category-topic/chromecast/discuss-and-give-feedback/setting-up-chromecast/other-os/hXZAvdvjk_w |
It seems Google does not want receivers outside the oficial one |
@frisco82 I have looked into YouMap Receiver apk and I don't blame Google for this Cease & Desist too much. That apk included big parts of proprietary Google Cast Receiver apk (and it was paid app on Google Play! Very daring and reckless...). Also there was no magic, there has been only |
@leo-labs thank you! |
@sashahilton00 , but how so many apps can act as a chromcast device, like airreceiver? |
Precomputed. Do a clean install and you'll see it has the same certificate. |
The developer of the app will be running a rooted chromecast and pushing new peer certificates to the app every 24/48 hours would be my guess. |
I can reproduce the certificate generation at each reinstallation of Reflector4, each time there is a new peer cert, and the signature sent in the AuthResponse is valid Reflector4, generated yesterday peer_cert
platform_cert
signature
Reflector4, generated today peer_cert
platform_cert
signature
The platform cert is the same, the peer cert is regenerated every 24h (and on reinstall) |
@si0ls about "chromecast_v1.6_content_shell.tgz" I found version 10 here (just in case it helps): https://github.com/githankH/chromecast-mirrored-source.chromium/blob/master/README Direct link: |
@forlayo Thanks, I found the (new) Gdrive root link : https://drive.google.com/drive/folders/0B3j4zj2IQp7MV2NZOVFPTDNzSTA All versions (v1.6 included) are present |
Have you observed a revocation of a device certificate? |
@si0ls This might help you: https://support.google.com/product-documentation/answer/10525328 I ever tried to install an chromecast apk that someone dumped from his rooted chromecast to my android phone, other phones can see it by pressing cast icon of youtube. but got failed when trying to connect to it. Check the log of my android phone, it said "no private key found" and other error messages. You can find all error message strings in the obj files from the above link. unfortunately, they are not source code that i have searched for so long. |
I haven't observed it directly to be fair. I have spoken with people that claim that after rooting their device and providing a key server that their device stopped working, but I haven't been able to confirm if that was down to revocation or some other issue. I'd be surprised if they didn't revoke it though - what would be the point of this walled garden approach if they didn't bother to keep it walled? |
@si0ls is the private key included in the app though? My guess is that it probably preloads a week of certificates or something - if it does indeed have a full keypair embedded, then it would be possible to make a cast receiver, on the assumption that Google didn't decide to revoke it. |
Decompiling Chromecast built-in (a.k.a. mediashell), which is an app intended to add Chromecast to Android TVs I saw these apps are producing a google's API url and asking for a certificate there. Just in case this is helpful for someone, you can generate the URL in this way:
The post is a regular post request done in this way:
On an emulator this doesn't works, but it should works on an Android TV; I haven't tested it yet. |
Bumping this issue again because after hours of searching, this is the single most promising lead I've been able to find for emulating a chromecast. |
Hi Seb, I'm glad to see that there are still some people interested in this topic. I've been trying to get my hands on an unpatched Chromecast gen1 for over a year now so I can root it and extract keys. I can't find any that have never been used, so I suspect that the companies offering software alternatives to the Chromecast are not faced with invalidated keys, and have had to extract, by some means I don't understand, a root key to generate as many certificates as desired. I sincerely believe that a good option would be to manage to reverse engine one of these apps to obtain their private Key and exploit it. As I recall, the keys used were children of the Chromecast gen1 root certificate, which has been deprecated by Google, so I wouldn't be surprised to see the certificate revoked in the near future. If you have any updates, don't hesitate to share them, I'm very curious to see how far we can go! Louis |
Probably I 'm able to put a "different" point of view about certification. Just for fun, I was able to recreate a simple pychromecast without "pychromecast" project from scratch. After that I said to me: why not do the inverse? And I'm doing the same inverting the process. Next time, I was putting in the place of "this issue", I'm not able to get a auth message because for some reason it's rejected. I supposed that this was for Certification Auto-Signed, and like an AOSP, you have to be signed in Google like developer (using a compiled app by you). Next time, I discovered castreceiver app and decompiling it I see that this certs could be signed in any Android device (with termux), so I do an script for that:
Et... voila. In any Android device you could obtain any valid signed certs. But for me this path is ended (because I don't know why you need this certifications). To run it download termux, launch a pkg install python and install dependencies with pip install cryptography. But... I'm very worried about other kind of issues, like I'm not able to get a right communication with Chromecast using the Chromium cast_channel.proto in python. With my server I was able to capture a package (welcome) and send it to a chromecast, but the answer is weird (because python said Error: Error parsing message A PoC can be found at my repo in develop branch: Today, I have a newer version with some PoC, but in this versions I not able to receive data from Chromecast if it's different from my "captured payload". I could offer a "dev dev" rev. of this file:
Other interesting project that has "auth" message working fine is: https://gitlab.gnome.org/GNOME/gnome-network-displays but for me in my laptop doesn't work (I don't know why). Just it's an investigation for a fun summer time. Greetings! |
@bitstuffing creating a chromecast client, which is what your code would work I think is the inverse point of what this project (node-castv2) is trying to solve. This projects aims to act as a server, to receiver for example the screenshare from a Chrome browser. And the issue with authentication is that the callenge you are receiving from a Chrome browser needs to be signed with a certificate that comes from same CA or otherwise that Chrome browser is going to reject you. In this same thread you could see examples of having this working modifying the chrome browser to not validate the signature but obviously is not what we want. There are many applications out there with this authentication working (AirServer, Reflector4, etc), then or the CA is exposed somehow or there is a trick we aren't seeing. |
Sorry if you understand me badly. I wanted to expose a case of use, but just to clarify what I did in my repository, my simple project has reversed the DIAL protocol, and it's working, like a server, with VLC Android clients, because VLC don't verify the CA server identification. The next steps were make "mirror" implementation. There are more branches than master for that "investigation". I suspected, because currently I don't investigate it anymore, that some applications has the "paid" ability (because it uses the Google API) to "generate" a valid CA like Cromecast or Google Home devices (because apparently they renew his CA each 48 hours). So, at this moment, if there is available some code to use a CA certification "method", I could reimplement it. But... the reality is there aren't open ways to do that (because Android clients verify the CA entity that signed the certification, and close/kill the connection). I just tried it. |
I'm working on it by referring to https://github.com/EiNSTeiN-/chromecast-widevine-tools, but an error is occurring because chromecast_v1.6_content_shell.tgz could not be imported during the build process. I looked for several links to download chromecast_v1.6_content_shell.tgz, but since they are all old Google Drive addresses, I cannot download them due to a 404 error. (Try all download link about https://github.com/Akheon23/chromecast-mirrored-source.chromium). |
You can try https://github.com/tristanpenman/chromecast-tools |
https://drive.google.com/drive/folders/0B3j4zj2IQp7Md2luZ0dFYUJhbnc (from https://github.com/EiNSTeiN-/chromecast-widevine-tools/issues/2) |
I have reverse engineered the AirReceiver application and made an open-source receiver which works with Google Chrome: https://github.com/rgerganov/shanocast You can find more info about how it works in this blog post |
Thank you for this clarification, which finally makes it possible to understand (and validate the hypotheses) how these apps work. |
Sorry for that, but... @rgerganov, your work is not useful because it doesn't touch the "thread" Anyway, thanks for the repo and the terms (because you're able to see how it works with docker and no compilation is required). The main trouble is you're not able to get valid ssl socket, because you're not able to get a valid certification, because Android client verify where you are signed your local certification, and close the connection. Anyway, people using "reverse-engineering-API" from working Android APKs could be great because there is using "custom" unknown process to get this certification, but... this is not the case. Thanks in advance for your work, but we're in a dead end :'( |
@bitstuffing Did you read his post? Didn't he succeed in getting regular Chrome to cast to this custom receiver? |
yes, I read, did you read the main title of this thread? The investigation focus should be in the reverse-engineering of Android apks, which has an .so file, which skip the problem That is just my worry, how to skip this problem and get a right certification from valid CA, to not be rejected from a normal client (each Android device and app, not VLC because it doesn't use Google API and doesn't verify the cert) |
He literally reverse engineered and Android apk and it's native library. quote from the post:
Are you sure you read his post? |
Well, no offense, now I know where is the misunderstand. I will you clarify the doubts, before answer quickly and write the evident. Chrome / Chromium doesn't verify the socket ssl CA. His work just allows use a server / client, based on openscreen (from chromium project code), and works with Chrome/Chromium (Google just put a client/server code to work with a proper autosigned certification, he just patched it to open the way to use it out of "localhost" environment, but not to any Android client, because he doesn't patch that, and the development, based on cast_channel.proto, just works with Chrome, not with Android, because neither Android cast_channel.proto is available, it's compiled in privated coded GAPPS) If you're sure that you're in a right thesis, test the repository final .bin, or test the docker. You could check how it works. Next check chrome code, check the openscreen code (it's refered in his repository), check how it works (there is attached a client and a server), and launch it. You could check than Android (S.O. and any apk using google api) will not detect anything. The thread must be focused in that, how we're obtaining a valid certification, to not be rejected by Android clients, because if all clients reject you (not chrome), this protocol is useless. Thanks for your big comprehension |
I understand, thank you for the clarification. |
I succeeded in rooting using the 1st generation Chromecast, and confirmed that it was searchable in the list of things that can be cast by passing authResponse based on Android. (Actual casting has not been implemented yet). However, in IOS, it is not searched in the list that can be cast with the same code. Is there any difference in authResponse between Android and IOS? One more thing, Chromecast 1st generation is not listed for casting on iOS and Android devices. |
I'm trying to understand device authentication right now and will post progress in this issue.
The text was updated successfully, but these errors were encountered: