Related
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.
MOD EDIT: Thread closed by OP's request.
If you have used reker's proxy, you will notice the "by @reker" entry on top of the list with search results. If we could do the same with the SamWP8 tool (and link his app to a similar app page), maybe we could bypass the interop unlock requirement (the error you receive if you try to sideload a app with interop capabilities on a non-interop unlocked phone) because apps installed in the store don't get this check (as compu829 demonstrated by saying the original Microsoft youtube app contained the ID_CAP_MEDIALIB_PHOTO_FULL entry in the WMAppManifest.xml, and how could you install this app on phones without having an interop-unlock, exactly : the app was installed through the store).
Correct me if I'm wrong, I'm still learning how the WP OS is build and how it functions.
To admins, I can't post this in the Windows Phone 8 Development and Hacking thread because I don't have the required 10 posts yet.
Seems like a feasible idea, I'll take a look on how the store works but I think the XAP's still need to be signed by a trusted root to this works.
I'll post any updates here as I can't post on dev section x.x
This idea is older than WP8, and it doesn't work. First of all, the apps themselves (as opposed to the data about them) are delivered over an encrypted channel that uses certificate pinning; we can't intercept or modify it. Second, the Store will only install Microsoft-signed (and probably only DRMed) apps. Unsigned apps failed to install through this channel back on WP7. Third, even if we could install the apps this way, hey would still be unsigned. The OS would thus treat them as developer apps. Developer apps on phones where the MaxUnsignedApp registry value is less than 300 are limited to the standard third-party app capabilities, meaning no INTEROPSERVICES or similar.
By all means, go ahead and poke at it - WP8 has surprised me before with weaknesses it has relative to WP7 - but don't expect this to work even if you get past the first issue (which *does* exist on WP8).
Did someone contact reker? We need to figure out how he did this. I can't tell if he succeeded into linking an app to the custom app page because when I click install, I get an error message : "This app is not available for your region", maybe I need to change my region to China and try again.
@GoodDayToDie : Won't the phone be tricked by the store installation, thinking it's an encrypted app? Does it matter whether the app is encrypted or not if someone manages to link an app to a custom app page, because Windows Phone app weren't always encrypted to my recollection (this may predate the WP8 era, if so we're screwed ). And if it matters, can we encrypt the app ourselves by using a encryption method like AES, SHA, MD5, ... ? Unlikely hypothesis, but if someone would succeed in doing all this, could the SamWP8 tool be used to increase the HKEY_Local_Machine\Software\Microsoft\DeviceReg\Install MaxUnsignedApp value beyond 300 to unlock interop capabilities? Are the EnableAllSideloading.xap and Bootstapper.xap also usable on other WP than Samsung or do they need to be recoded to work on WP of other manufacturers?
EnableAllSideloading.xap and Bootstapper.xap depends on Samsung diagnosis tool and it's RPC server that runs on LocalSystem account that has "unlimited" registry access, it's not available on other manufacturers.
Tonight I will start my experiments on it.
greenboxal said:
EnableAllSideloading.xap and Bootstapper.xap depends on Samsung diagnosis tool and it's RPC server that runs on LocalSystem account that has "unlimited" registry access, it's not available on other manufacturers.
Tonight I will start my experiments on it.
Click to expand...
Click to collapse
I was wondering how you could flash the bootloader of Android on the Ativ S as the Secure Boot made by Qualcomm is locked by a blown fuse (it's a hardware issue, not only a software issue you must deal with).
bruce142 said:
I was wondering how you could flash the bootloader of Android on the Ativ S as the Secure Boot made by Qualcomm is locked by a blown fuse (it's a hardware issue, not only a software issue you must deal with).
Click to expand...
Click to collapse
SecureBoot checks signature of the bootloader by a known public key, the case is that Samsumg uses the *same* key for android and wp8 bootloaders.
greenboxal said:
SecureBoot checks signature of the bootloader by a known public key, the case is that Samsumg uses the *same* key for android and wp8 bootloaders.
Click to expand...
Click to collapse
If this checks out, what does it mean, could we flash android on the Ativ S? Or could you even make a dual-boot scenario possible? Great find by the way, :good:.
bruce142 said:
If this checks out, what does it mean, could we flash android on the Ativ S? Or could you even make a dual-boot scenario possible? Great find by the way, :good:.
Click to expand...
Click to collapse
Yes, it's the same hardware as SGS3 Snapdragon 4 version. But let go back to the topic, if you have some question about it send me a PM or post on my R&D thread
greenboxal said:
Yes, it's the same hardware as SGS3 Snapdragon 4 version. But let go back to the topic, if you have some question about it send me a PM or post on my R&D thread
Click to expand...
Click to collapse
I can't post yet in your R&D thread because I don't have the met the 10 post requirement yet.
Edit : I can install reker's "by @ reker" app when changing the region to China, and this is interesting (pasted directly from his WMAppManifest.xml) :
<?xml version="1.0" encoding="UTF-8"?>
-<Deployment AppPlatformVersion="8.0" xmlns="http://schemas.microsoft.com/windowsphone/2012/deployment">
<DefaultLanguage xmlns="" code="zh-CN"/>
-<Languages xmlns="">
<Language code="zh-Hans"/>
</Languages>
-<App xmlns="" PublisherId="{9b1d1b5b-f206-4b27-a139-89659591061b}" IsBeta="false" PublisherID="{b259af64-2f7d-4a89-983f-836325480629}" Publisher="智机网_WPXAP" Description="智机市场官方版" Author="智机网_WPXAP" Genre="apps.normal" Version="2.0.0.0" RuntimeType="Silverlight" Title="智机市场" ProductID="{59bd999b-496e-4e05-afce-94b67ba6e862}">
<IconPath IsResource="false" IsRelative="true">Assets\ApplicationIcon.png</IconPath>
-<Capabilities>
<Capability Name="ID_CAP_IDENTITY_DEVICE"/>
<Capability Name="ID_CAP_IDENTITY_USER"/>
<Capability Name="ID_CAP_NETWORKING"/>
<Capability Name="ID_CAP_PUSH_NOTIFICATION"/>
<Capability Name="ID_CAP_SENSORS"/>
<Capability Name="ID_CAP_WEBBROWSERCOMPONENT"/>
<Capability Name="ID_CAP_APPOINTMENTS"/>
</Capabilities>
-<Tasks>
<DefaultTask Name="_default" ActivationPolicy="Resume" NavigationPage="MainPage.xaml"/>
</Tasks>
-<Tokens>
-<PrimaryToken TaskName="_default" TokenID="WpXapToken">
-<TemplateFlip>
<SmallImageURI IsResource="false" IsRelative="true">Assets\Tiles\FlipCycleTileSmall.png</SmallImageURI>
<Count>0</Count>
<BackgroundImageURI IsResource="false" IsRelative="true">Assets\Tiles\FlipCycleTileMedium.png</BackgroundImageURI>
<Title/>
<BackContent/>
<BackBackgroundImageURI/>
<BackTitle/>
<DeviceLockImageURI/>
<HasLarge/>
</TemplateFlip>
</PrimaryToken>
</Tokens>
-<Extensions>
<Protocol Name="wpxap" TaskID="_default" NavUriFragment="encodedLaunchUri=%s"/>
</Extensions>
-<ScreenResolutions>
<ScreenResolution Name="ID_RESOLUTION_WVGA"/>
<ScreenResolution Name="ID_RESOLUTION_WXGA"/>
<ScreenResolution Name="ID_RESOLUTION_HD720P"/>
</ScreenResolutions>
</App>
</Deployment>
@bruce142: The store may or may not care about the DRM - that was in place by the time WP8 came out, but WP7 didn't have it for a long time - but it absolutely cares about the signatures. More accurately, actually, the XAP install code (which the store invokes) cares about the signatures. There's no "tricking" it; the signature is quite plainly there, or it's not. You don't exactly have to look hard to find it. The app launch code *also* cares about signatures. Non-sideloaded apps won't have ID_CAP_DEVELOPERUNLOCK, which is a special capability automatically added to sideloaded apps to allow them to launch even though they don't have signatures. Without that capability (or rather, without the SID which the token of an app with that capability gets at chamber creation), the kernel will refuse to load the unsigned executable binaries.
GoodDayToDie said:
@bruce142: The store may or may not care about the DRM - that was in place by the time WP8 came out, but WP7 didn't have it for a long time - but it absolutely cares about the signatures. More accurately, actually, the XAP install code (which the store invokes) cares about the signatures. There's no "tricking" it; the signature is quite plainly there, or it's not. You don't exactly have to look hard to find it. The app launch code *also* cares about signatures. Non-sideloaded apps won't have ID_CAP_DEVELOPERUNLOCK, which is a special capability automatically added to sideloaded apps to allow them to launch even though they don't have signatures. Without that capability (or rather, without the SID which the token of an app with that capability gets at chamber creation), the kernel will refuse to load the unsigned executable binaries.
Click to expand...
Click to collapse
I understand, the app has to be signed before it can be uploaded to the store, but does the developer of an app not sign its app when he assembles it or does the store sign the app itself? I see no threshold here, as signing an app is not a problem, or is it? I still admire that reker managed to make an app page by using a proxy which isn't normally there and successfully linked an app to it, which I was able to download and it contained elevated capabilities, I thought the ID_CAP capabilities were all interop capabilities (correct me if I'm wrong). Could someone make the old version of the Samsung Diagnostic tool available this way which users with other WP than the Ativ S/Ativ S Neo might able to use to modify the MaxAppUnsigned value and unlock more capabilities, or is this impossible? If only we knew how reker did this, ...
bruce142 said:
I understand, the app has to be signed before it can be uploaded to the store, but does the developer of an app not sign its app when he assembles it or does the store sign the app itself? I see no threshold here, as signing an app is not a problem, or is it? I still admire that reker managed to make an app page by using a proxy which isn't normally there and successfully linked an app to it, which I was able to download and it contained elevated capabilities, I thought the ID_CAP capabilities were all interop capabilities (correct me if I'm wrong). Could someone make the old version of the Samsung Diagnostic tool available this way which users with other WP than the Ativ S/Ativ S Neo might able to use to modify the MaxAppUnsigned value and unlock more capabilities, or is this impossible? If only we knew how reker did this, ...
Click to expand...
Click to collapse
ID_CAP's aren't all Interop capabilities, most of them are available for every app, and the ones you posted are, afaik, normal ones that don't need and Interop Unlock.
GoodDayToDie is right. His answer is very detail.
You may replace a xap with homebrew one in theory, but phone will never launch a store app without MS signature. Every single dll is signed by MS, and phone will check it.
Few questions and opinions:
The signature is used only for allowing the app to be installed on the device right?
Is the signature after added to the app a constant for the whole time or is it changing from time to time?
If the signature is used only for allowing an app to be installed, can we somehow make an virtual MS Server (Using FIddler for example), who can clone the real one and give us an offline signing of the app`s when installing them?
Can a signature be pulled off from an original installed app and the be put in to an another one?
cevi said:
Few questions and opinions:
The signature is used only for allowing the app to be installed on the device right?
Is the signature after added to the app a constant for the whole time or is it changing from time to time?
If the signature is used only for allowing an app to be installed, can we somehow make an virtual MS Server (Using FIddler for example), who can clone the real one and give us an offline signing of the app`s when installing them?
Can a signature be pulled off from an original installed app and the be put in to an another one?
Click to expand...
Click to collapse
The signature is checked when running the application, every PE image on the device should have a valid digital signature.
You don't seem to understand how it works, the signature is any kind of hash, let's say, SHA256, of the entire file. This signature is encrypted with the signee private key. If you change one single bit of the file, the hash will change, and so the signature will be invalid.
There are few ways to exploit this kind of security, like generating a hash collision or breaking the private key, both would take million of years.
I do really don't understand the whole process I was just giving some noob suggestions.
It's strange for me that after the app is installed it doesn't require an active network to start.So I am wondering if it could be possible to trick the app to start somehow?
Sent from my Windows Phone 8S by HTC using Tapatalk
While suggestions are always welcome, you really should read up on digital signatures and how they work. @greenboxal's explanation seems like it might have gone over your head a bit... The fact that you didn't understand about ID_CAP_* also means you've probably never looked at WP development, or even looked at the manifest of a WP app, either; you may want to do some of that. Until you do so, it would be only by the sheerest crazy luck that you managed to hit on a solution, because you don't even know what you're actually trying to accomplish!
For example, it's pretty obvious why there's no need for a network connection to start an app, once it's installed. There's a license on WP apps, which is checked when the app is installed (requires Internet access) and is then valid for some time (never checked how long exactly, probably years though). The signatures are different. When the app is installed, the signing certificate (which contains the public key, but not the private key, of the keypair used to sign the app) is extracted from the app and checked to see whether it is trusted by Microsoft (the phone has Microsoft's certificates embedded in the OS; it doesn't need a network connection for this). When you try to launch the app, it checks to see whether the signatures on each binary (which are, as greenboxal mentioned, created by taking the cryptographically secure hash of the binary and then applying something like encryption to it using the private key) are valid (it applies the public key to the signature to get the signing hash back, and checks whether that hash still matches). We (developers) can't fake store signatures ourselves, because we don't have Microsoft's private keys. Therefore the phone wouldn't trust our signatures (make sure you read up on the concept of a "chain of trust" and the concepts of public key cryptography and public key infrastructure in general too) and would refuse to load the binaries. The process of verifying signatures is just a bunch of math once you've already got the public keys, and those are, as I said, extracted from the app at install (for individual apps) and stored in WP8 itself (for the Store-wide signing key); no need to access the network.
Thanks guys for clearing this up for me.I know that it`s not that simple as i say.Anyway, just keep up the good work.We the Noobs depend from you.
If you are not those who you really are i personally know that i will never buy a Windows Phone again.You are the reason for the MS`s profit.
Sorry again for jumping in into this "battle".
This thread is becoming way out of hand, question is asked and answered : adding a app via proxy which may interop-unlock other WP is not possible. Locking thread now.
PS : yay, ten posts.
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.
So I just saw the the little news about towelroot on the xda front page I'm wondering if that would work with the chromecast? Should I unplug this thing to stop updates or what?
Asadullah said:
So I just saw the the little news about towelroot on the xda front page I'm wondering if that would work with the chromecast? Should I unplug this thing to stop updates or what?
Click to expand...
Click to collapse
Sadly, I don't think it has any effect on Chromecast.
The trouble is that towelroot is an APK.
Chromecast won't let you sideload APKs due to whitelist.
Non-vulnerable Chromecast won't load unsigned code from bootloader/recovery.
Because you can't "just run an app" the way to get root on Chromecast is by flashing a pre-rooted ROM.
The only way to flash a ROM is to use FlashCast, which requires a vulnerable bootloader, because FlashCast is not signed by Google.
Non-vulnerable bootloaders will only run Google-signed code.
Thus, the existing root methods for Chromecast remain:
FlashCast on vulnerable bootloaders only
Replace the firmware/bootloader via physical chip removal and reprogramming
Once the bootloader gets (auto) updated, you can't flash anything because the bootloader will not execute FlashCast.
Another possibility would be to use a Chrome sandbox escape vulnerability and try to execute the kernel exploit this way - good luck with that :/
deeper-blue said:
Another possibility would be to use a Chrome sandbox escape vulnerability and try to execute the kernel exploit this way - good luck with that :/
Click to expand...
Click to collapse
That's an idea, but the trick is getting Chrome to execute the exploit to begin with... Essentially the Chromecast whitelist acts like parental control on a router - Chromecast can only access approved addresses unless it's been made a developer unit.
bhiga said:
That's an idea, but the trick is getting Chrome to execute the exploit to begin with... Essentially the Chromecast whitelist acts like parental control on a router - Chromecast can only access approved addresses unless it's been made a developer unit.
Click to expand...
Click to collapse
And even if you could manage to get it to run inside CCast Chrome...I'm sure the Sandbox seals it off from making any changes to the root or bootloader status.
bhiga said:
That's an idea, but the trick is getting Chrome to execute the exploit to begin with... Essentially the Chromecast whitelist acts like parental control on a router - Chromecast can only access approved addresses unless it's been made a developer unit.
Click to expand...
Click to collapse
There is one thing that comes to mind. The Netflix client on the Chromecast runs as native code out of /netflix/. I have a feeling there is some sort of vulnerability exposed there
neobear said:
There is one thing that comes to mind. The Netflix client on the Chromecast runs as native code out of /netflix/. I have a feeling there is some sort of vulnerability exposed there
Click to expand...
Click to collapse
possible... but you gotta find it, use it, then hope the big G doesn't push an update to fix it soon after.
-= this post enhanced with bonus mobile typos =-
neobear said:
There is one thing that comes to mind. The Netflix client on the Chromecast runs as native code out of /netflix/. I have a feeling there is some sort of vulnerability exposed there
Click to expand...
Click to collapse
Still have the issue being that the only way to launch it is via Netflix...
bhiga said:
possible... but you gotta find it, use it, then hope the big G doesn't push an update to fix it soon after.
-= this post enhanced with bonus mobile typos =-
Click to expand...
Click to collapse
even if they do it can be rooted therefore and updates blocked.. hence mission accomplished... like Sony's ps3.. I think sunny finally had given up now...
Sent from my Nexus 5 using Tapatalk
persianrisk said:
even if they do it can be rooted therefore and updates blocked.. hence mission accomplished... like Sony's ps3.. I think sunny finally had given up now...
Click to expand...
Click to collapse
Yes, much like the current bootloader exploit that FlashCast uses. It becomes major cat-and-mouse because Chromecast auto-updates without waiting for user intervention though.
Sony can give up more easily because a game console's success is not as heavily tied to content providers. Chromecast, on the other hand, would be sunk without any apps. Let's face, Chromecast for YouTube alone just won't cut it, even at $35.
bhiga said:
Yes, much like the current bootloader exploit that FlashCast uses. It becomes major cat-and-mouse because Chromecast auto-updates without waiting for user intervention though.
Sony can give up more easily because a game console's success is not as heavily tied to content providers. Chromecast, on the other hand, would be sunk without any apps. Let's face, Chromecast for YouTube alone just won't cut it, even at $35.
Click to expand...
Click to collapse
I understand. but Sony is equally tied to game content and also other media providers - hence when it was hacked its a bigger problem as some choose not to purchase their games whereas with rooted Chromecast you are still paying for the services even if using a proxy...
Sent from my Nexus 5 using Tapatalk
persianrisk said:
I understand. but Sony is equally tied to game content and also other media providers - hence when it was hacked its a bigger problem as some choose not to purchase three have whereas with rooted Chromecast you are still paying for the second albeit unusually through a proxy...
Click to expand...
Click to collapse
True, it does create an interesting secondary market.
8-31-21: My report on the death of this app for the NST is a little premature. See post #5, etc., for a "fix". It worked for the poster and it worked for me. It might work for you.
Don't shoot the messenger...
Sometime in late 2020 or early 2021 it became impossible to negotiate an initial login with the Kindle app (yes, even with the OTP they email you). I've checked the security certificates and they are fine. I've tried installing the app on newer devices, going all the way to Oreo. Same behavior. A logcat on the NST shows a failed SSL negotiation so it looks like the server just won't talk to the old app any longer--at least for an initial authorization. That's the very bad news.
There is a tiny bit of good news for those who already have the Kindle app installed and authorized. At least on my three devices it continues to function completely. You can still check out Overdrive Kindle books and send them to your device and the same book on different devices appears to sync. You can also sideload .mobi books and read those. The clock is, however, probably ticking.
I mention this as a warning for anyone who has a legacy Kindle installation and is thinking of doing major work on their device. If you uninstall or wipe out the Kindle app, it's gone for good. It may be possible to use something like Titanium Backup to restore the app. I was able to find all this out after a reset and then restore my NookManager backup and the app worked fine.
Edit: I have done a little experimenting and the app authorization token appears to include a lot about the device and system. So it's not possible to use Titanium Backup. I tried this on a FW 1.2.1 installation with a working copy of Kindle. Then I updated and rooted FW 1.2.2, installed the Kindle app and then restored a Titanium backup from the same device (but with FW 1.2.1). It failed to initialize, asking to register again. I've had success only in restoring a NookManager backup from the same device with the same FW, etc., and in cloning a device from a NookManager backup. This is not something I would necessarily recommend, but you might have your reasons. However, when I tried to correct the MAC address, this threw off the Kindle app token and it reverted to asking for registration again. So there's very little wiggle room for preserving a working installation if you have to do any significant changing.
I have seen your report in the thread where you were trying to help another forum member to overcome the issues he had with his device. This strengths my beliefs that for resolving the SSL issue work on kernel(s) must be done. Question is where exactly? In Linux kernel or somewhere in Android? What SSL is used on NST if the snag is in Linux - OpenSSL or LibreSSL?
In the defense of the NST I must say that recently saw on YouTube video someone put Alpine Linux on Kindle PW3. What am I trying to say is that older generation of this kind of devices suffer from same illness regardless of brand manufacturer pushing people to just abandon the legacy software on them and create their own custom made one tailored for their devices and their intended way of use.
If the SSL layer is somewhere in Android oh boy that might be harder cookie to bake from my point of view.
SJT75 said:
I have seen your report in the thread where you were trying to help another forum member to overcome the issues he had with his device. This strengths my beliefs that for resolving the SSL issue work on kernel(s) must be done. Question is where exactly? In Linux kernel or somewhere in Android? What SSL is used on NST if the snag is in Linux - OpenSSL or LibreSSL?
In the defense of the NST I must say that recently saw on YouTube video someone put Alpine Linux on Kindle PW3. What am I trying to say is that older generation of this kind of devices suffer from same illness regardless of brand manufacturer pushing people to just abandon the legacy software on them and create their own custom made one tailored for their devices and their intended way of use.
I
Click to expand...
Click to collapse
SJT75 said:
I have seen your report in the thread where you were trying to help another forum member to overcome the issues he had with his device. This strengths my beliefs that for resolving the SSL issue work on kernel(s) must be done. Question is where exactly? In Linux kernel or somewhere in Android? What SSL is used on NST if the snag is in Linux - OpenSSL or LibreSSL?
Click to expand...
Click to collapse
My understanding of the issues is very limited. I once happened into a discussion where it was stated that apps which need to communicate with external servers contain their own SSL certificate which has an expiration date. If so, apps like that just die a "natural" death.
It's actually amazing that there are some apps requiring logins that still work on the NST. Two that come to mind are ancient versions of Pandora and TuneIn Radio. I use both and they still perform flawlessly. For now.
Until today I didn't know what Pandora is but I am familiar with TuneIn radio app. Good to know that some of those apps is still working. Well it just had to be complicated with SSL/TLS hidden somewhere in Android layer. I totally understand why people like Android user friendly UI and apps availability. Still gamble with Java seems that didn't paid of regarding promised platform crossing ability.
So either porting to a new Android version which probably will not be very new (low RAM) or making custom Linux which is anything but user friendly?
Edit: Scratch that question about Linux and the app OP mentioned! I just realize that there is no Linux Kindle app. It could be used through Wine and such witchcraft but that is stupid way of doing things on this device. Better option is to use it on PC and then pass it on to NST using Calibre IMHO. SSL/TLS although remains as weak spot for the time being. Oh well... If that issue with certificates get somehow fixed maybe Kindle cloud reader from browser could reclaim at least part of functions of dedicated Kindle app.
For what its worth I recently got a NST and managed to get the kindle app running this morning. I upgraded to FW 1.2.2, rooted with Nook Manager, and installed the app with adb. The sticking point for me was that I had to go into my Amazon account and disable two-factor authentication. When I tried to log in with the app it still gave the bad password error, and Amazon still sent a text message with an OTP, and that let me log in. This same process DID NOT work if I had two-factor auth turned on in my Amazon account.
I don't understand why they still sent an OTP when two-factor auth is turned off, but they did, and it worked.
wrexroad said:
For what its worth I recently got a NST and managed to get the kindle app running this morning. I upgraded to FW 1.2.2, rooted with Nook Manager, and installed the app with adb. The sticking point for me was that I had to go into my Amazon account and disable two-factor authentication. When I tried to log in with the app it still gave the bad password error, and Amazon still sent a text message with an OTP, and that let me log in. This same process DID NOT work if I had two-factor auth turned on in my Amazon account.
I don't understand why they still sent an OTP when two-factor auth is turned off, but they did, and it worked.
Click to expand...
Click to collapse
Wow! This is very good news. I'll give it a try tomorrow on a fresh system and see if I can get it to work.
Did you by any chance go back and turn on the two-factor login and see if the app still connected after first initializing it?
nmyshkin said:
Wow! This is very good news. I'll give it a try tomorrow on a fresh system and see if I can get it to work.
Did you by any chance go back and turn on the two-factor login and see if the app still connected after first initializing it?
Click to expand...
Click to collapse
Yes, I should have mentioned that. I re-enabled two-factor and downloaded a book to test, everything worked fine. I'm currently using this (https://forum.xda-developers.com/t/app-eink-friendly-amazon-kindle-3-2-0-35.2024062/) version of the app, but I don't think it should matter much.
wrexroad said:
Yes, I should have mentioned that. I re-enabled two-factor and downloaded a book to test, everything worked fine. I'm currently using this (https://forum.xda-developers.com/t/app-eink-friendly-amazon-kindle-3-2-0-35.2024062/) version of the app, but I don't think it should matter much.
Click to expand...
Click to collapse
Excellent. As I expected based on legacy installs continuing to work, once the credentials are on the device, you're good to go whether you use single or two factor login after.
I had a password issue with Amazon awhile back and I'll bet that's where the problem originated. When I changed my password, authentication must have gone to two-factor. I need to check that, but I'm pretty sure that's it. What great news! Back to seamless library book checkout and download, all on the device!
BTW, the version of the app you mention is the only one that works (again!) on the NST.
Something is weird on the Amazon side right now. Even though two factor was turned off, they still sent the OTP. The only difference is that it actually worked when two-factor was disabled, but didn't work when it was enabled. Very strange.
wrexroad said:
Something is weird on the Amazon side right now. Even though two factor was turned off, they still sent the OTP. The only difference is that it actually worked when two-factor was disabled, but didn't work when it was enabled. Very strange.
Click to expand...
Click to collapse
Mmm... I'm glad you posted this before I started testing. I have two NSTs with working Kindle apps right now and I don't want to trash those while tracking down the "solution". I need to think about how I'm going to approach this.
OK, I think my last message was a little unclear.
What I meant was that with two-factor enabled you are supposed to be able to log in with a legacy device, have it give you a password error, receive an OTP via text or email, then use the OTP to actually log in. However, this does not work when two-factor is enabled.
What does work is first disabling two-factor auth, then trying to log in. You will still get a password error, they will still send you an OTP and the OTP will now let you log in and register the device.
This is what I meant when I said something was weird, when two-factor is disabled they shouldn't even be sending you an OTP. It's like disabling two-factor makes it work correctly, rather than turning it off.
To be absolutely clear, once I registered the app, I was able to download a book when two-factor was either on or off. The only thing that was affected was the ability to do the initial sign in.
wrexroad said:
OK, I think my last message was a little unclear.
What I meant was that with two-factor enabled you are supposed to be able to log in with a legacy device, have it give you a password error, receive an OTP via text or email, then use the OTP to actually log in. However, this does not work when two-factor is enabled.
What does work is first disabling two-factor auth, then trying to log in. You will still get a password error, they will still send you an OTP and the OTP will now let you log in and register the device.
This is what I meant when I said something was weird, when two-factor is disabled they shouldn't even be sending you an OTP. It's like disabling two-factor makes it work correctly, rather than turning it off.
To be absolutely clear, once I registered the app, I was able to download a book when two-factor was either on or off. The only thing that was affected was the ability to do the initial sign in.
Click to expand...
Click to collapse
OK, that's what I had hoped for and expected since my two working installs were made before my auth. got changed to two-factor. With really old apps you never quite know how server negotiation is going to evolve.
I hope to give it a try later today.
wrexroad said:
To be absolutely clear, once I registered the app, I was able to download a book when two-factor was either on or off. The only thing that was affected was the ability to do the initial sign in.
Click to expand...
Click to collapse
When I went to my Amazon account it seemed like 2SV was not enabled, by which I mean that clicking on "edit" for the settings generated an email which contained a link that took me to a page with a button that said "Get Started".
I didn't pursue this. I didn't see anything about turning it off--or should I have gone farther along?
That's odd, it does sound like it's not turned on... If you didn't have other devices that you were worried about I would say that you should just turn it on then try to log in. If that doesn't work, turn it off and try again. I think the risk is minimal, but clearly there is something different about your account, so it's up to you.
wrexroad said:
That's odd, it does sound like it's not turned on... If you didn't have other devices that you were worried about I would say that you should just turn it on then try to log in. If that doesn't work, turn it off and try again. I think the risk is minimal, but clearly there is something different about your account, so it's up to you.
Click to expand...
Click to collapse
Yeah, this is not working for me. I looked at the 2SV stuff again this morning and thought, "well, I'll just set it up and then disable it". Except I don't own a mobile phone (no, truly, just an emergency ancient (non-text message) device I keep in my glove compartment), and the QR thingy woud do me no good with the NST. So I'm cooked.
Despite apparently not having 2SV set up, now I can't even generate an OTP email when I try to login with the Kindle app. But my two working installations continue to function. Puzzlement.
Edit: I had a friend with a mobile phone help me out. So I finally got to where I could "disable" 2SV. But it made no difference. Still can't log in or even generate an OTP email by trying to log in. I'm glad this worked for you and I'd like to think it might work for others, but alas my account appears to be "special".
Edit-Edit: Yeehaw! It took a lot of fumbling for me with the unwieldy password I had to recreate in the near past, but by clearing the dalvik cache and making sure that 2SV was actually listed as "disabled" at Amazon, I was finally able to log in a new installation!!! Now I don't have to run a "clone" of another device on this particular NST. Thank you, @wrexroad, for taking the time to look into this and communicate your findings. One big step back from the brink for the Kindle app
That's awesome, I'm glad you got it running! In the future, if you need to get a password via text, you can use a temporary number here: https://sms24.me/en/countries/us/
Hey folks,
I just stumbled into this NST world and want to share my experience with the Kindle app. I'm on FW 1.2.2, and used NookManager to root. I replaced the certs file as recommended in another thread. Once I was ready to login, I enabled 2fa on my Amazon account in a browser. The instructions there clarified that I would need to use PASSWORD+OTP when registering my device. Previously I had tried only the OTP, or only my normal passwrord, but those failed. Appending the OTP to my password, I was able to login.
Hope that helps anyone else who has reached this point.