Database Develop

Chromecast "emulator"

Since chromecast simply get an url or data to play content already "on the cloud", it will be possibile to emulate its behaviour with a chrome extension or something like that?
I'd love to use a chromecast-like interface on my desktop pc...

p.nightmare said:
Since chromecast simply get an url or data to play content already "on the cloud", it will be possibile to emulate its behaviour with a chrome extension or something like that?
I'd love to use a chromecast-like interface on my desktop pc...
Click to expand...
Click to collapse
I'd second that. I'd love to see the ability to chrome cast TO a (widows) chrome browser.
I have a number of MCE PC's connected to HD TV's and computer with monitors throughout the house that would be great as the recipients of "casting".
At work I'd like to be able to look something up on my phone and then sent it to my nearest PC browser...

htcsens2 said:
I'd second that. I'd love to see the ability to chrome cast TO a (widows) chrome browser.
I have a number of MCE PC's connected to HD TV's and computer with monitors throughout the house that would be great as the recipients of "casting".
At work I'd like to be able to look something up on my phone and then sent it to my nearest PC browser...
Click to expand...
Click to collapse
You mean like this? - http://goo.gl/NOoel
You won't be able to push Netflix to the browser the same way, but you can certainly do so with web content.

Jason_V said:
You mean like this? - http://goo.gl/NOoel
You won't be able to push Netflix to the browser the same way, but you can certainly do so with web content.
Click to expand...
Click to collapse
Yeah kind of like that but completely integrated into he chrome cast infrastructure and APIs so that it is compatible across all apps and is just one click on the new "cast" buttons that are cropping up at the top of all my Android apps now .... (Netflix, Youtube, Google music etc.)
There has been talk of 3rd party hardware makers being encouraged to support the standard so shouldn't be too hard to do proper chrome browser integration as a target.

I can't believe no one has thought of it yet :fingers-crossed:

here
p.nightmare said:
I can't believe no one has thought of it yet :fingers-crossed:
Click to expand...
Click to collapse
Here you go github.com/dz0ny/leapcast

dz0ny said:
Here you go github.com/dz0ny/leapcast
Click to expand...
Click to collapse
awesome! I will definitely keep an eye on that :good: :good:

Nodecast is also an option
p.nightmare said:
awesome! I will definitely keep an eye on that :good: :good:
Click to expand...
Click to collapse
Beside Leapcast (which is implemented in python), there is a JavaScript-/Node.js-Port in Git-Hub available. The port was made by Sebastian Mauer, the guy who wrote Cheapcast.
I spend the last weekend exeperimenting with both Nodecast and Cheapcast. Now Nodecast runs here in a Windows 8.1 virtual machine - and I'm able to stream from other Windows and Android-devices.
I wrote a few tutorials, how to setup Nodecast on Windows (it also possible to use similar steps in Mac OS X or Linux). The tutorial is currently only in German - but Google translate shall do the job.
Nodecast setup for Windows-tutorial: http://goo.gl/2ZU5Mm
Maybe it helps

Leapcast 2.0?
Anyone still working on Leapcast now that the 2.0 SDK came out? Lots of changes like going from DIAL to mDNS for one. Leapcast was very handy for running on a PC that was already connected to the TV. Sadly, all the apps compiled against the newer SDK won't work with it. They won't even discover it as a Chromecast now.

https://chrome.google.com/webstore/...oakcolegkcddbk?utm_source=chrome-app-launcher
This was an attempt to do this but I never got it to work on my side.

Unfortunately, SDK 2.0 requires the Chromecast to calculate key using certificate issued by Google. We will probably wait a long time to see leapcast, CheapCast and NodeCast working again. It might not be even possible at all.

Johny_G said:
Unfortunately, SDK 2.0 requires the Chromecast to calcate key using certificate issued by Google. We will probably wait a long time to see leapcast, CheapCast and NodeCast working again. It might not be even possible at all.
Click to expand...
Click to collapse
Not the best news, but thanks Johny for the insight.
If all the rooted ROMs can handle SDK 2.0 and Google's new authentication, there's probably a way to get the emulators up and running with it. Just a matter of time and determination I hope. I wish Google was a bit more open on the software side for the Chromecast. Having the new SDK for sender/receiver apps is great, but allowing companie/people to recreate the piece in the middle would also benefit them I would think. It would be tough for people to beat the Chromecast's price tag, but having other options would be good.

Averix said:
Not the best news, but thanks Johny for the insight.
If all the rooted ROMs can handle SDK 2.0 and Google's new authentication, there's probably a way to get the emulators up and running with it. Just a matter of time and determination I hope. I wish Google was a bit more open on the software side for the Chromecast. Having the new SDK for sender/receiver apps is great, but allowing companie/people to recreate the piece in the middle would also benefit them I would think. It would be tough for people to beat the Chromecast's price tag, but having other options would be good.
Click to expand...
Click to collapse
I wouldn't hold my breath. The ROMs get the upgrade essentially "for free" as it's part of the stock ROM code. Maybe the desktop players can take advantage of that, probably not, especially if it's a binary or relying on some kind of TPM or other function in the Chromecast hardware itself.
Having options is good for the consumer, but for a manufacturer, more options = more competition = more mouths to feed = lower margins = more work to keep competitive. One of the reasons Apple is so aggressive about protecting the exclusivity of its platform.

Warning! TL;DR below!
The point is, that every single Chromecast device has its unique ID, its unique MAC Address, and its (unique?) signed certificate. Also, it might have some kind of ID generated when you set the device up (similar to Push ID used in Google Cloud Messaging). Some of those (maybe all of them) have to play together to calculate the key. As soon as you pull the certificate out and put it in different environment, the result of the calculation won't match the SDK's expectations. So there is pretty good chance, that bypassing the key might be completely impossible without modifying the SDK itself (and it would require the developers to actually invest some effort to support these alternatives) and maybe the Chromecast device software as well. But who knows, the guys involved in those "emulators" are way smarter than most of us and might figure something out .
This is the biggest issue. The other one is, that everything has changed in the new SDK/API, and all of the methods used in those emulators are now deprecated and need to be implemented all over again in a different fashion to work with 2.0. This might actually be a good thing, since developers involved in testing of the way-too-rushed 1.0 seemed not to have a lot of kind words to say about it. I have attended one Chromcast block on a local conference, and it was basically 2 hours of swearing.
I've stumbled upon these issues today (and a bit of yesterday), trying to get my app working in the office (I forgot my Chromecast at home - again), and here are some sources if you are more interested in the topic:
https://plus.google.com/+SebastianMauer/posts/83hTniKEDwN
https://github.com/dz0ny/leapcast/issues/29#issuecomment-37288608
https://github.com/dz0ny/leapcast/issues/96
As a developer, I have to say, that Google is making things awfully difficult lately, and the "don't be evil" policy seems to slowly fade away. They put way too much effort into marketing decisions, and have no time to properly test APIs and SDKs before they spit them out . Mostly, when trying some new Android-related technology (to be honest, its mostly Google Play Services technology these days, so AOSP starts to be completely useless), I spend most of the time working around things that nobody thought of (i.e. the Translucency API in KitKat was obviously tailored for Google Now Launcher, and is a huge PITA tu be used elsewhere) and fixing the broken samples that come with them. It might seem weird, but sometimes (say hello to Play Games Services and in-app billing v1+v2!) the sample is inseparable part of the final implementation, so you have to fix their rushed code anyway. I shouldn't be complaining, since things like that raise the value of developers willing to go through all of this in their spare time, but the change of philosophy still bugs me a lot. Google and Android used to be strongly community-oriented, and now the marketing is pulling it all away.

Should the goal really be to emulate a Chromecast or should the effort be geared toward supporting DIAL protocol?
I would think the latter is the better option because you could support whatever the hardware supports without the limitations imposed on us from CCast Hardware.
Maybe I'm wrong but I always looked at DIAL as an extension of UPnP and separate from the CCast itself and the Chromecast SDK as not much more than a kit to add DIAL support to Android (and iOS) not meant to build anything on the CCast side at all.
Other companies like Roku are planning some DIAL support and I doubt highly they will have a CCast ID and Certificate.
In the end I think we will get something similar to this functionality from a player app like VLC on PC and MAC, or perhaps in Chrome itself.
Cause I think (and I may be totally wrong here) that it isn't the Apps we use that checks the Whitelist and IDs it is the CCast itself that when invoked to load a player app to stream it also checks the whitelist and tests security before it plays.
SO if someone created a program for PC that made the PC announce itself as a DIAL capable device that when connected to loads the app into Chrome, I bet most of it would work.
Might not work with any of the DRM sites like Netflix and Hulu but for things like local content and unprotected streams I see no reason why it wouldn't.
In fact I bet the trouble some are having with Channels in Plex and others would go away because a PC Chrome instance would be able to play many more Transport types than a CCast can currently.

Asphyx said:
Should the goal really be to emulate a Chromecast or should the effort be geared toward supporting DIAL protocol?
I would think the latter is the better option because you could support whatever the hardware supports without the limitations imposed on us from CCast Hardware.
Maybe I'm wrong but I always looked at DIAL as an extension of UPnP and separate from the CCast itself and the Chromecast SDK as not much more than a kit to add DIAL support to Android (and iOS) not meant to build anything on the CCast side at all.
.......
Click to expand...
Click to collapse
I agree with you. I could actually care less about emulating the specifics of what's in the Chromecast hardware. What I do want is the ability for those unrestricted apps (ie not Netflix) to be able to use their Cast button to find, connect to, and use whatever the emulator is. The new CC SDK doesn't use DIAL to do the initial search any longer. It now uses mDNS. All of the previous apps (YouTube, Pandora, etc.) are still using the old API and DIAL discovery which appears to be backward compatible with the new Chromecast stick software. If you look at the debug logs of the stick, both the v1 and v2 APIs are accounted for. As for Roku, my guess (I haven't started digging in on what they're up to yet) is that they have an app that is using DIAL for discovering the Roku and then just acting as a remote control for all the box functions. Chromecast was a bit more unique since it could basically load up anything from the web as a receiver/playback client since the software is just basically a Chrome browser with some wrappers around it. That's what made it much more dynamic without having to load "channels" in the box within a custom framework like Roku does.
And Bhiga, as for economics on Google providing the software to other hardware makers, I think it it would actually be in their best interest. The Chromecast right now has to be either close to at cost for them or a loss leader. If they can get the Cast API to become a default standard on new consumer devices, that would help them take over that space. To me, that is such a better proposition for them than trying to get the complexities of something like GoogleTV into TVs.

Averix said:
And Bhiga, as for economics on Google providing the software to other hardware makers, I think it it would actually be in their best interest. The Chromecast right now has to be either close to at cost for them or a loss leader. If they can get the Cast API to become a default standard on new consumer devices, that would help them take over that space. To me, that is such a better proposition for them than trying to get the complexities of something like GoogleTV into TVs.
Click to expand...
Click to collapse
mDNS actually makes discovery a lot easier - mDNS = Bonjour = what Apple and TiVo use for discovery already.
I agree with you that adoption of the API and protocols is the goal. At this stage an Android emulator probably would help adoption, but my point was that a desktop emulator doesn't necessarily add to the rate. If someone starts looking to using a desktop because they think they don't need a Google Cast device, they'll likely runs across Plex and Miracast and may decide they don't need Google Cast at all.

bhiga said:
I agree with you that adoption of the API and protocols is the goal.
Click to expand...
Click to collapse
I wish Google agreed with us.

Averix said:
I wish Google agreed with us.
Click to expand...
Click to collapse
I bet anything there are some at Google who do agree with us but when your as BIG a company as Google is it takes forever to get everyone on board and thinking along the same lines enough to manifest it into an end product.
In the end what all if this really tells us is how much DLNA Consortium has failed to standardize Media Distribution by not going far enough and thinking of it from the end user ergonomic experience.
If this discovery and launch capability was more fleshed out in the DLNA specs we might not be talking about DIAL and mDNS right now.
At some point all these protocols (DLNA, UPnP, DIAL) should be merged into one standardized protocol that any platform can use.
Probably years away though...

Asphyx said:
If this discovery and launch capability was more fleshed out in the DLNA specs we might not be talking about DIAL and mDNS right now.
At some point all these protocols (DLNA, UPnP, DIAL) should be merged into one standardized protocol that any platform can use.
Probably years away though...
Click to expand...
Click to collapse
My concern is that unless Google is willing to push this as a standard rather than just apps for one dongle, it will only be a matter of time before the giant (un)friendly fruit company swoops in and AirPlay becomes the defacto standard that all TV makers, set top makers, and anyone else are forced to build in. It's not quite the same as how DLNA and UPnP have become sort of irrelevant, but it could pan out that way for the Google Cast API without more hardware devices having the capability built in. Time and market pressure will tell I guess.

[DEV] Intercept chromecast whitelist with MITM (and update)

Hi All,
I've just managed to successfully intercept and change the whitelist for a flashed chromecast.
Steps:
Load custom cert onto device (replace nssdb with custom one) - nssdb I used and certs available here https://mega.co.nz/#!05wmDR4T!OMkBXwfO9D1wktt2bQpSwjNZ_Y9PB8q_Ryk3zSx4k1c
Load MITM on a linux host, route default gateway at linux host.
Route just google range towards MITM (so nothing else gets caught and just gets redirected)
iptables -t nat -A PREROUTING -p tcp -s 192.168.178.146 -m iprange --dst-range 74.125.237.0-74.125.237.255 -j REDIRECT --to-port 8080
load mitmproxy with
"mitmproxy -T --host -s chromefree.py"
chromefree.py is available https://mega.co.nz/#!doJX1YDS!TT3lolbgXta24QOpbj40PBAYRetZkH1s9cIvQBslBN8
note that chromefree.py refrences json.dat (which requires a gzip'd json file)
example json files are available here https://mega.co.nz/#!ghwAEI7D!a-HwECm4w_8XKfdaaZOLgFrVTx9B8xLMOYJchi1PAUY
(with this I redirected youtube to a local news site, so attempting to cast to youtube pulls up stuff.co.nz)

Appears to work well, here's a picture of my TV running the revision 3 app
http://i.imgur.com/nhLI0oC.jpg

While I applaud this news, this could likely be the reason why Google has been slow to throw the doors open. The big name media providers are probably really leaning on Google to make sure these kinds of hacks can't possibly take place.
While everyone knows that no system is infallible, I'm sure that Google is under pressure to make sure that the device is as airtight as it can possibly be, and then some, before permitting the SDK to be formally released to the public.

mkhopper said:
While I applaud this news, this could likely be the reason why Google has been slow to throw the doors open. The big name media providers are probably really leaning on Google to make sure these kinds of hacks can't possibly take place.
While everyone knows that no system is infallible, I'm sure that Google is under pressure to make sure that the device is as airtight as it can possibly be, and then some, before permitting the SDK to be formally released to the public.
Click to expand...
Click to collapse
Do you really think that people would be spending so much time trying to circumvent the whitelisting if the content was available from the get go. I was very optimistic at the start but losing patience now. I bought three and was ready to buy more, but will wait and see what happens. Don't want to invest more money and time into something that might not have a future. It is sad because it has the unprecedented potential for so many different uses.

Can this be dumbed down for the newbs

ramirez3805 said:
Can this be dumbed down for the newbs
Click to expand...
Click to collapse
I plan to have a service available for rooted chromecast in the next few days that allows access to non-google approved applications.

Kyonz said:
I plan to have a service available for rooted chromecast in the next few days that allows access to non-google approved applications.
Click to expand...
Click to collapse
Cant wait!!!:good:

networx2002 said:
Cant wait!!!:good:
Click to expand...
Click to collapse
You don't have to! I just released last night http://forum.xda-developers.com/showthread.php?t=2516164

Kyonz said:
Appears to work well, here's a picture of my TV running the revision 3 app
http://i.imgur.com/nhLI0oC.jpg
Click to expand...
Click to collapse
What did you use as the sender app?

so i have a question how do you load up an app for use in chromecast now that i have done this ? sorry for sounding so noobish but just wondering.

ahecht said:
What did you use as the sender app?
Click to expand...
Click to collapse
I used the demo html app sender to launch it (sorry not entirely sure on the name as I haven't started developing for chromecast yet). I'd really like to see someone try to reverse engineer the data that the receivers require and build apps out for these though.

BurnOmatic said:
so i have a question how do you load up an app for use in chromecast now that i have done this ? sorry for sounding so noobish but just wondering.
Click to expand...
Click to collapse
This really is a DEV thread in that it provided the exploit for chromecast, app launching would be through the demo dev apps - please check out Kyocast (http://forum.xda-developers.com/showthread.php?t=2516164) if you haven't and note that there are better things coming

Kyonz said:
I used the demo html app sender to launch it (sorry not entirely sure on the name as I haven't started developing for chromecast yet). I'd really like to see someone try to reverse engineer the data that the receivers require and build apps out for these though.
Click to expand...
Click to collapse
I must be dense, as I can't make heads or tails of the Chromecast API (I usually can't understand Google's documentation for the Android API either, but there are plenty of third-party resources for that). What do you use for Launch Parameters in the demo app?

Which boot loader number is vulnerable ? I can#t find the infos :/

12alex21 said:
Which boot loader number is vulnerable ? I can#t find the infos :/
Click to expand...
Click to collapse
Only build 12072 has a vulnerable bootloader. You have to boot into the stock OS and set the Chromecast up (on a Wi-Fi network which doesn't connect to the internet or else it will update automatically) to check the build number.

Unable to root but food for thought.

Okay, I messed up and mis-spelled eureka-image while rooting and didn't pay attention and let the device update after I rebooted it after a couple hours of being gone then I was stuck in google locked down build.
Well this got me thinking if we can't root can we make "Chromecast" believe we are using Google Movies when in fact it is a 3rd party app?
Wouldn't we just need to find the string that communicates that the 3rd party app is Google Movies, or Pandora or any of the Official Apps?
I could be wrong but I think there is away to make it work but it'll have to be built in the 3rd party's app.
Thoughts?

maxjivi05 said:
Okay, I messed up and mis-spelled eureka-image while rooting and didn't pay attention and let the device update after I rebooted it after a couple hours of being gone then I was stuck in google locked down build.
Well this got me thinking if we can't root can we make "Chromecast" believe we are using Google Movies when in fact it is a 3rd party app?
Wouldn't we just need to find the string that communicates that the 3rd party app is Google Movies, or Pandora or any of the Official Apps?
I could be wrong but I think there is away to make it work but it'll have to be built in the 3rd party's app.
Thoughts?
Click to expand...
Click to collapse
The Chromecast utilises a whitelisting type file in which applications that it will respond to is presented, unfortunately if it isn't aware of an application it wont show up in the list for that device (due to the dial protocol).
We can't man in the middle non rooted devices as the whitelist received is provided through https and therefore is not easily attacked (trust me I've spent more than enough hours trying).

maxjivi05 said:
Okay, I messed up and mis-spelled eureka-image while rooting and didn't pay attention and let the device update after I rebooted it after a couple hours of being gone then I was stuck in google locked down build.
Well this got me thinking if we can't root can we make "Chromecast" believe we are using Google Movies when in fact it is a 3rd party app?
Wouldn't we just need to find the string that communicates that the 3rd party app is Google Movies, or Pandora or any of the Official Apps?
I could be wrong but I think there is away to make it work but it'll have to be built in the 3rd party's app.
Thoughts?
Click to expand...
Click to collapse
I had thought about this just before KyoCast appeared, but I'm pretty sure it would be against the DIAL registry's registration and/or Cast SDK's license for an app to impersonate another app. I still like the concept though.
Actually, even if an app used another app's DIAL ID, the whitelist would still point the Chromecast-side app to the real app, (ie, phone might run SneakyApp by Chromecast would still launch its Google Movies app), I think.

Man this is awful they went through all this effort to limit users :/
Okay, now I know all the apps require to be pulled up differently on Chromecast but what about if we mimic "Casting Tab" which I believe is driven by the host computer and Chromecast is only listening and displaying what it see's. I'm sure it's secured with HTTPS too but HTTPs isn't that secure but you'd probably need a certificate if they are authenticating but if not it would be as easy as sniffing a handshake and injecting that packet then utilizing that connection. Sorry I'm thinking outside the box! lol
Sent from my HTC6435LVW using Tapatalk

bhiga said:
I had thought about this just before KyoCast appeared, but I'm pretty sure it would be against the DIAL registry's registration and/or Cast SDK's license for an app to impersonate another app. I still like the concept though.
Actually, even if an app used another app's DIAL ID, the whitelist would still point the Chromecast-side app to the real app, (ie, phone might run SneakyApp by Chromecast would still launch its Google Movies app), I think.
Click to expand...
Click to collapse
it is probably ok to use someone else's player in an App you wrote but it is probably not ok to say you are their App that also uses it.
I can certainly see Real Player making their CCast (DIAL) Player App available to 3rd Party developers to use for other projects like NFL and MLB streams that require DRM as part of their Content Creator packages.
Maybe you know (I'm sure Team Eureka would have an idea) if it is the Apps we run that are Whitelisted or the Apps that actually play on the CCast that are restricted by the Whitelist. I'm betting the Latter...

As I know it, the whitelist controls everything Chromecast "runs."
Sent from a device with no keyboard. Please forgive typos, they may not be my own.

[Q] Could it be possible to install an OTA update from a different OTA server?

Is there anyway of installing an OTA update from a different OTA server? Maybe routing the OTA server's address to a local personal OTA server address and forcing the Chromecast to install a rooted ROM?

Yes, but you have to be rooted to do it.

MadBob said:
Yes, but you have to be rooted to do it.
Click to expand...
Click to collapse
Hence the chicken-and-egg scenario...
The OTA server communication goes through HTTPS, so Chromecast has its security certificate.
If you were to do a MITM attack, you don't have Google's certificate, so the HTTPS request will fail.
It would be easy if you could add your server's certificate to Chromecast.
But that requires having root, which we don't have.
Also, the secure bootloader will only load Google-signed code.
So you'd need to have Google's private key, which nobody but Google has.
Running a custom player app (that runs on Chromecast) to find a vulnerability is challenging too.
In order to run a "custom" player app, you need to sign up to be a Google dev.
The player app will only run for your registered Chromecast(s), not anyone else's.
Adding to that, almost all apps run in a Chrome sandbox.
In order for a player app to run for everybody, it Google has to put it on their whitelist.
Which essentially means even if you were to find a vulnerability, Google would be able to yank your player app almost immediately.
Then Google would patch the exploit and release a new firmware...
Stock Chromecasts auto-update and you can't (yet) choose not to accept the update, so you can't avoid the update while still being able to use Chromecast (this might be possible through router blocking/redirection - not sure).
So what does that leave?
A client-side app that somehow takes advantage of a vulnerability in an existing Chromecast player app or service.
Google would still be able to force the developer to update the app, or they themselves could update the firmware, but at least a client-side app could be available for Chromecasts with builds still vulnerable to it, similar to how FlashCast is available for Chromecasts that still have the vulnerable bootloader.
...and of course the existing FlashCast for those few Chromecasts that still have the vulnerable bootloader.
Wish I was artsy enough to make an infographic, heh.

...

bhiga said:
In order for a player app to run for everybody, it Google has to put it on their whitelist.
Which essentially means even if you were to find a vulnerability, Google would be able to yank your player app almost immediately.
Click to expand...
Click to collapse
You know that fact poses an interesting question....
We already have people redirecting DNS to change location...
How hard would it be to redirect a call to the Whitelist server and redirect it to another that has a Whitelist that is not controlled by Google?
It would have to be done at the router since you can't change it in the CCast without root but it should be possible to redirect the link to some other Whitelist that we could add any app we wanted to it.
Are there any other security checks tat would prevent it? I tend to doubt it as we have been able to download the App list via PC and I'm pretty sure that App list is the main Whitelist (I could be dead wrong here)

Asphyx said:
You know that fact poses an interesting question....
We already have people redirecting DNS to change location...
How hard would it be to redirect a call to the Whitelist server and redirect it to another that has a Whitelist that is not controlled by Google?
It would have to be done at the router since you can't change it in the CCast without root but it should be possible to redirect the link to some other Whitelist that we could add any app we wanted to it.
Are there any other security checks tat would prevent it? I tend to doubt it as we have been able to download the App list via PC and I'm pretty sure that App list is the main Whitelist (I could be dead wrong here)
Click to expand...
Click to collapse
Essentially it's the same problem as redirecting the Google OTA server.
It's HTTPS and therefore requires that Chromecast has the server's certificate, adding the certificate requires root.
I do not believe HTTPS can be redirected in a simple rerouted response manner.

bhiga said:
Essentially it's the same problem as redirecting the Google OTA server.
It's HTTPS and therefore requires that Chromecast has the server's certificate, adding the certificate requires root.
I do not believe HTTPS can be redirected in a simple rerouted response manner.
Click to expand...
Click to collapse
Yes but server certificates are enforced on the server side aren't they?
Perhaps not....

Just to add to @bhiga's excellent explanation: it is actually possible to run a custom web-based player on an unrooted Chromecast, since several whitelisted apps (for example, Google's "TicTacToe" demo app) are served over plain, unencrypted HTTP. That means that a potential root exploit has the ability to load arbitrary HTML/JavaScript on the device. However, this gets us nowhere because of web apps' inherent lack of trust and Google's extensive sandboxing to prevent accidental vulnerabilities (I wrote more on this here).
With regard to the original question, even if we were able to bypass the HTTP certificate checking of the updater, the Chromecast's recovery would still refuse to apply our rooted update since it wouldn't be signed with Google's keys. If this weren't the case, we would simply be able to craft an update file that installed the original, vulnerable bootloader to the device and from there use FlashCast like we do now.
---------- Post added at 05:34 PM ---------- Previous post was at 05:25 PM ----------
Asphyx said:
Yes but server certificates are enforced on the server side aren't they?
Perhaps not....
Click to expand...
Click to collapse
The Chromecast contains a list of trusted certificates for "google.com" locally, and only Google has the private keys which allow them to serve files using those certificates (I'm simplifying quite a bit here; if you're interested in the actual "certificate authority" system used, Wikipedia has a good overview) . We can't modify the trusted certificate list without root, and we can't get root (using any of the methods discussed here, at least) without having the private key to a trusted certificate for "google.com". So it's a chicken-and-egg problem, just like any well-designed security model is. (If you already have the keys to the kingdom, it's easy to do whatever you want. Getting the keys is the hard part.)

tchebb said:
The Chromecast contains a list of trusted certificates for "google.com" locally, and only Google has the private keys which allow them to serve files using those certificates (I'm simplifying quite a bit here; if you're interested in the actual "certificate authority" system used, Wikipedia has a good overview) . We can't modify the trusted certificate list without root, and we can't get root (using any of the methods discussed here, at least) without having the private key to a trusted certificate for "google.com". So it's a chicken-and-egg problem, just like any well-designed security model is. (If you already have the keys to the kingdom, it's easy to do whatever you want. Getting the keys is the hard part.)
Click to expand...
Click to collapse
Thanks. I was under the (false apparently) impression that the Server was the one that did Cert checks not the client and if the client did not have the proper cert the Server could send one or deny sending it data.
But I guess your saying that the CCast will also check to see if the Cert is valid on the server side before it will accept communication.
Which would require a Google Cert on the Server side.

Rooting beenfits

Hi all
Think it would be about £25-£30 to get all the kit to root the Chromecast, which then will most probably not be used again. Can anyone please explain the benefits of rooting? Such as what the rooted ROM's will give me over official firmware. For example am I able to run XBMC from it?
I have most probably been lucky in the past because it has cost nowt to root my smartphones, tablets etc?
I am all for rooting Chromecast but not sure of the benefits.
Regards
fs1023

fs1023 said:
Hi all
Think it would be about £25-£30 to get all the kit to root the Chromecast, which then will most probably not be used again. Can anyone please explain the benefits of rooting? Such as what the rooted ROM's will give me over official firmware. For example am I able to run XBMC from it?
I have most probably been lucky in the past because it has cost nowt to root my smartphones, tablets etc?
I am all for rooting Chromecast but not sure of the benefits.
Regards
fs1023
Click to expand...
Click to collapse
No it won't let you run XBMC....
Two most noteworthy benefits to root...One may actually be something you might like.
1 - You get to use the Eureka Whitelist which can allow some apps to work earlier than they they would because Google has delayed whitelisting it. (Screen Mirroring was available to rooted users even before Google announced it because rooted users had it whitelisted while Google waiting until Google IO) What those Apps are varies as they are released and as Google adds them to their list so a comprehensive list is not really possibe.
2 - (And the one that might interest you most since you appear to be in the UK)...Rooted makes it much easier to use VPNs and custom DNS settings so you can access region blocked content without the need for complex settings changes on your router which can sometimes affect other services. As time goes on this may be the most used feature for those not in the US and want to access full content from Netflix and Hulu. or even those in the US who would like access to content that is blacked out in the US and only available in Europe.
In time as more people are able to get root you might find some more developers willing to create apps that take advantage of the rooted CCast but there are Millions of units sold and I'm not sure but I'm betting less than 100K actually have achieved root in the initial hack and perhaps now many more will be able to boost those numbers.

Is that £25-30 including the Chromecast price. Because if you have a memory stick already, the teensy and usb otg Y cable is about £10.

Asphyx said:
No it won't let you run XBMC....
Two most noteworthy benefits to root...One may actually be something you might like.
1 - You get to use the Eureka Whitelist which can allow some apps to work earlier than they they would because Google has delayed whitelisting it. (Screen Mirroring was available to rooted users even before Google announced it because rooted users had it whitelisted while Google waiting until Google IO) What those Apps are varies as they are released and as Google adds them to their list so a comprehensive list is not really possibe.
2 - (And the one that might interest you most since you appear to be in the UK)...Rooted makes it much easier to use VPNs and custom DNS settings so you can access region blocked content without the need for complex settings changes on your router which can sometimes affect other services. As time goes on this may be the most used feature for those not in the US and want to access full content from Netflix and Hulu. or even those in the US who would like access to content that is blacked out in the US and only available in Europe.
In time as more people are able to get root you might find some more developers willing to create apps that take advantage of the rooted CCast but there are Millions of units sold and I'm not sure but I'm betting less than 100K actually have achieved root in the initial hack and perhaps now many more will be able to boost those numbers.
Click to expand...
Click to collapse
Asphyx thanks for your knowledgeable reply, you have convinced me to root.
theronkinator said:
Is that £25-30 including the Chromecast price. Because if you have a memory stick already, the teensy and usb otg Y cable is about £10.
Click to expand...
Click to collapse
theronkinator thanks as well for your reply. Looked at prices in OP and they seemed to be more that £10. Thanks anyway I will shop around.
Will this product do the same as the Teensy? A-Star 32U4 Micro

fs1023 said:
Will this product do the same as the Teensy? A-Star 32U4 Micro
Click to expand...
Click to collapse
I managed to root my four chromecasts using an A-Star 32U4 micro.
The LEDs don't light up at all during the process and there's no reset button so you have a short a couple of pins, but apart from that it works fine.
Tim

ClarkyCat said:
I managed to root my four chromecasts using an A-Star 32U4 micro.
The LEDs don't light up at all during the process and there's no reset button so you have a short a couple of pins, but apart from that it works fine.
Tim
Click to expand...
Click to collapse
Thanks for the reply Tim. No sure what you mean by " there's no reset button so you have a short a couple of pins". I have tried to put the teensy hex file on it but it does not work. Do I need to do this part of rooting? Can you please explain the process of how you rooted your 4 casts?
Regards
fs1023

fs1023 said:
Thanks for the reply Tim. No sure what you mean by " there's no reset button so you have a short a couple of pins". I have tried to put the teensy hex file on it but it does not work. Do I need to do this part of rooting? Can you please explain the process of how you rooted your 4 casts?
Regards
fs1023
Click to expand...
Click to collapse
You need to get the A-Star into bootloader mode in order to load in the HubCap teensy files (I used regular_16664.hex). There's no reset button on the board so you have to short the GND and RST pins twice within 750ms. The board LED kind of pulses when it's in bootloader mode.
Have a read of the docs here: http://www.pololu.com/docs/0J61/5.3
I programmed the board using:
Code:
avrdude -p atmega32u4 -c avr109 -P /dev/ttyACM0 -U flash:w:regular_16664.hex
Perform the root in exactly the same way as in the youtube vid. The only difference is that the LED on the A-Star doesn't flash in the same way as the teensy++ in the vid does. You just have to watch for the Chromecast LED colour change.
Cheers,
Tim

ClarkyCat said:
The only difference is that the LED on the A-Star doesn't flash in the same way as the teensy++ in the vid does. You just have to watch for the Chromecast LED colour change.
Click to expand...
Click to collapse
Actually, try the hex files I attached to my post on the HubCap thread.
I've rebuilt them with A-Star 32u4 LED support, so it blinks the same way as the teensy2++ does in the vid.
Tim

ClarkyCat said:
You need to get the A-Star into bootloader mode in order to load in the HubCap teensy files (I used regular_16664.hex). There's no reset button on the board so you have to short the GND and RST pins twice within 750ms. The board LED kind of pulses when it's in bootloader mode.
Have a read of the docs here: http://www.pololu.com/docs/0J61/5.3
I programmed the board using:
Code:
avrdude -p atmega32u4 -c avr109 -P /dev/ttyACM0 -U flash:w:regular_16664.hex
Perform the root in exactly the same way as in the youtube vid. The only difference is that the LED on the A-Star doesn't flash in the same way as the teensy++ in the vid does. You just have to watch for the Chromecast LED colour change.
Cheers,
Tim
Click to expand...
Click to collapse
Once again thanks Tim your help is much appreciated.
Not really sure what I am doing here but I have installed the Winavr software. When I click on run I get dialogue box error message - Error loading "C:WinAVR-20100110/bin/avr-gcc.exe": not in executable format: File format not recognised.-
Any idea what i am doing wrong?
Regards
fs1023

fs1023 said:
Once again thanks Tim your help is much appreciated.
Not really sure what I am doing here but I have installed the Winavr software. When I click on run I get dialogue box error message - Error loading "C:WinAVR-20100110/bin/avr-gcc.exe": not in executable format: File format not recognised.-
Any idea what i am doing wrong?
Regards
fs1023
Click to expand...
Click to collapse
I used linux, so I'm not sure about using winavr - is it supposed to provide some kind of cygwin-ish shell? Perhaps you need to run it with Admin privileges?
You'll need to change the -P parameter to whatever format windows needs. The user guide suggests "\\\\.\\USBSER000".
Tim

ClarkyCat said:
I used linux, so I'm not sure about using winavr - is it supposed to provide some kind of cygwin-ish shell? Perhaps you need to run it with Admin privileges?
You'll need to change the -P parameter to whatever format windows needs. The user guide suggests "\\\\.\\USBSER000".
Tim
Click to expand...
Click to collapse
Ok thanks Tim. I will buy a Teensy as this looks easier to work from. Would have bought one in first place but hard to find online for UK.
Regards
fs1023

Hello people, quick noob question.
I can stream something from a website to my phone but when I mirror my phone to tv, the tv screen goes blank and just hear the sound.
Is this something I can fix with rooting chromecast?
Sent from my LG-D802 using XDA Free mobile app

reggaetonero said:
Hello people, quick noob question.
I can stream something from a website to my phone but when I mirror my phone to tv, the tv screen goes blank and just hear the sound.
Is this something I can fix with rooting chromecast?
Sent from my LG-D802 using XDA Free mobile app
Click to expand...
Click to collapse
Hi reggaetonero
I have not yet rooted the Chromecast so I don't know what root brings. Sorry I can't help. You might be best either starting a new thread with with your question or maybe posting it here.
http://forum.xda-developers.com/har.../root-hubcap-chromecast-root-release-t2855893
Regards
fs1023

reggaetonero said:
Hello people, quick noob question.
I can stream something from a website to my phone but when I mirror my phone to tv, the tv screen goes blank and just hear the sound.
Is this something I can fix with rooting chromecast?
Click to expand...
Click to collapse
Rooting Chromecast won't help in this case as the problem is likely some capability missing from your phone or its ROM.

ClarkyCat said:
Actually, try the hex files I attached to my post on the HubCap thread.
I've rebuilt them with A-Star 32u4 LED support, so it blinks the same way as the teensy2++ does in the vid.
Tim
Click to expand...
Click to collapse
hey, is there any chance you could help me by showing which section you altered in the source to change the LED pin ?
as im trying to get a sparkfun board LED going ! cheers
EDIT cannot see where to delete post, as i think you just answered this in a dif thread ! as i posted this ... Thankyou EDIT

Deleted. It was a bit OTT, have had a bad day. Sorry if I offended anyone who has previously helped.

fs1023 said:
What a waste of money to root this thing. £20 odd for the teensy £5 odd for the OTG cable. I have sent various posts asking how you view eureka whitelist after root, as well how you use ssh and what the cc password is because when i have tried ssh in putty it asks me for username then password. I may as well have saved my money because all i have are the same apps as what i can get from google. total wast of money.
Click to expand...
Click to collapse
think yourve missed the point a bit then !
plus you didnt HAVE to spend that amount to get it going,
a under £10 ATmega 32U4 equiv is ok, plus you can make a OTG cable for free...
plus its future proofing IF sothing come out later
and its a great hobby too !