Database Develop

Setup question - technical query

I have my Chromecast already set up, and am forging ahead with learning and reading tricks on here, but I was curious about the set up process itself.
Think about it - I have an encrypted WiFi, and there's no open WiFi around me... But somehow when I was setting up the device, the program on my laptop knew the code that the device was broadcasting. The device clearly communicated out to the internet BEFORE I set up my WiFi password in the setup program. I'm wondering what the trickery was that managed that, or am I missing something critical in the process here?

FractalSphere said:
I have my Chromecast already set up, and am forging ahead with learning and reading tricks on here, but I was curious about the set up process itself.
Think about it - I have an encrypted WiFi, and there's no open WiFi around me... But somehow when I was setting up the device, the program on my laptop knew the code that the device was broadcasting. The device clearly communicated out to the internet BEFORE I set up my WiFi password in the setup program. I'm wondering what the trickery was that managed that, or am I missing something critical in the process here?
Click to expand...
Click to collapse
Pretty sure the device uses ad-hoc WiFi and/or Bluetooth to perform the initial sync. There is a thread about how your desktop must have a WiFi card in order to set up the chromecast (but Streaming from Chrome over ethernet works after initial setup).

Louer Adun said:
Pretty sure the device uses ad-hoc WiFi and/or Bluetooth to perform the initial sync. There is a thread about how your desktop must have a WiFi card in order to set up the chromecast (but Streaming from Chrome over ethernet works after initial setup).
Click to expand...
Click to collapse
Didn't think about an ad-hoc solution. And the setup program could be set to look for its broadcasts... Nor did I even consider using anything other than my laptop on WiFi to sit RIGHT IN FRONT OF THE TV and play while setting it up.
That sounds plausible, though it felt like wizardry at the time.

FractalSphere said:
Didn't think about an ad-hoc solution. And the setup program could be set to look for its broadcasts... Nor did I even consider using anything other than my laptop on WiFi to sit RIGHT IN FRONT OF THE TV and play while setting it up.
That sounds plausible, though it felt like wizardry at the time.
Click to expand...
Click to collapse
I thought the same thing at first, but after setting up my second Chromecast using the Android application, you can see it messing with your WiFi/Bluetooth settings in the status bar when initially searching for Chromecast devices.

Rooted Chromecast with Web Panel = Problems with security

I was playing with it only for one few hours...
and I am concerned with current level of security of rooted Chromecast.
If you
reboot wireless router(wireless access point)
OR
wireless router is down/malfunction
OR
communication between Chromecast and wireless router is jammed
OR
someone used Aircrack-ng suite to disconnect Chromecast from wireless router
your Chromecast just created open wireless network for configuration purposes...
and Team-Eureka http panel is accessible at most likely default IP address 192.168.255.253,
also provides you with an IP adress via internal dhcp.
look a bit at config:
http://192.168.255.249/?page=status
and than
http://192.168.255.249/?page=settings
be sure that telnet, ssh, adb are running.
Just connect with telnet or SSH, privledged user is root, there is no password
cat /data/wifi/wpa_supplicant.conf
Code:
ctrl_interface=/data/wifi
update_config=1
country=US
network={
ssid="my wifi essid"
scan_ssid=1
psk=my password on a silver plate in WPA PSK HEX(64 characters)
proto=RSN
key_mgmt=WPA-PSK
}
You just owned someone's Chromecast and can abuse his wireless network.
Still got time tinker with Chromecast? Maybe plant some android type of backdoor... NSA style...
How to fix this?
1. be sure that internal web server is not vurnelable.
2. https
3. Http panel accessible only after providing password that is by default for instance sha-1 hash of serial number.
(user may take a picture of his own chromecast and use tool/service to generate hash), it should be changed at first login
4. adb, telnet, ssh disabled by default
5. root password
Basic stuff...

First off, if you are worried about our panels security it is open source, so feel free to audit it for any vulnerabilities.
Also, we are working on a new revision of the panel which not only includes password support, but also the ability to set a SSH password. The reason none is set ATM is because by default the root acc on the chromecast has none, so we have a modified dropbear binary that will allow any password to work.
As for HTTPS over the web panel, that will be available, but it will not be "enforced". (at least that is the current plan). We may add a panel option that enforces https though, for users who are concerned about security on their local wireless network.
Now telnets another story, because its generated with busybox its hard to have a password enforced, but you can just disable it. same goes with ADB.
We know right now our services are not the most locked-down, but trust me most of it has already been fixed on our end and these changes will be out with the next OTA

ddggttff3 said:
First off, if you are worried about our panels security it is open source, so feel free to audit it for any vulnerabilities.
Also, we are working on a new revision of the panel which not only includes password support, but also the ability to set a SSH password. The reason none is set ATM is because by default the root acc on the chromecast has none, so we have a modified dropbear binary that will allow any password to work.
As for HTTPS over the web panel, that will be available, but it will not be "enforced". (at least that is the current plan). We may add a panel option that enforces https though, for users who are concerned about security on their local wireless network.
Now telnets another story, because its generated with busybox its hard to have a password enforced, but you can just disable it. same goes with ADB.
We know right now our services are not the most locked-down, but trust me most of it has already been fixed on our end and these changes will be out with the next OTA
Click to expand...
Click to collapse
Thank you for fast and exhaustive answer.
Any "ETA" of build with features you mentioned ?
Is there any roadmap for Eureka-ROM?
Any chance for something dedicated to LAN streaming?
(Chrome full screen is buggy, Plex is $ app, Fling is written in JAVA and no longer in developement.)
If there will be any beta or rc I am willing to participate.(not so many things to test there)

mathorv said:
Thank you for fast and exhaustive answer.
Any "ETA" of build with features you mentioned ?
Is there any roadmap for Eureka-ROM?
Any chance for something dedicated to LAN streaming?
(Chrome full screen is buggy, Plex is $ app, Fling is written in JAVA and no longer in developement.)
If there will be any beta or rc I am willing to participate.(not so many things to test there)
Click to expand...
Click to collapse
We don't really do ETA's but we try to have updates out right after google OTA's, or when there is a severe bug. As for a roadmap, we currently don't have one public due to it constantly changing.
LAN streaming still works with Fling (as we have fling added back to our roms through our whitelist service), but that is all I know of. If other users want to create apps that can utilize fling, that would be awesome.
And last for testing, currently I have more then enough testers for when beta updates roll out. keep your eyes open in the future as I may do open signups again at a later date.

Well the scenarios you set would apply to non rooted CCasts as well...
If they hacked your wireless with Aircrack to set a disconnect, then you were exposed long before they reconfigured the CCast and they can do a lot more damage with that access without you ever noticing than they could through the CCast.
Your would notice the CCast changing but you wouldn't notice someone hacked your Wireless without looking at the Router Logs or noticing a degraded Network performance.
If these things are a concern for you then I suggest you turn on MAC Filtering on our Router, Set Allows for the CCast and all the devices you own and deny all others.
But the concerns you have exist regardless of a rooted CCast. Leaving a CCast unconnected might expose the CCast to be taken over since it will be an open AP anyone can connect to....And they can Airtcrack you router even with a stock CCast.
But if you see that just look out the window because they would probably have to be sitting on your Porch or parked in your Driveway to do it!
I don't know many Hackers who are THAT Brazen! LOL

Asphyx said:
Well the scenarios you set would apply to non rooted CCasts as well...
If they hacked your wireless with Aircrack to set a disconnect, then you were exposed long before they reconfigured the CCast and they can do a lot more damage with that access without you ever noticing than they could through the CCast.
Your would notice the CCast changing but you wouldn't notice someone hacked your Wireless without looking at the Router Logs or noticing a degraded Network performance.
If these things are a concern for you then I suggest you turn on MAC Filtering on our Router, Set Allows for the CCast and all the devices you own and deny all others.
But the concerns you have exist regardless of a rooted CCast. Leaving a CCast unconnected might expose the CCast to be taken over since it will be an open AP anyone can connect to....And they can Airtcrack you router even with a stock CCast.
But if you see that just look out the window because they would probably have to be sitting on your Porch or parked in your Driveway to do it!
I don't know many Hackers who are THAT Brazen! LOL
Click to expand...
Click to collapse
Reconfiguring stock Chromecast is one thing and that's not so much a problem. Attacker don't get password, just info about name of connected network. In that scenario attacker gets essid and handshakes or reconfigure Chromecast wireless settings(essid/password).
Problem is that with rooted attacker has access to adb/telnet/ssh. In that scenario attacker has easy access to essid/password in plain text and may do this unnoticed.
About ranges:
What if someone lives in center of a city? Skyscrapers area?
About suburban area, I am not convinced that people in US live in houses with brick/concrete block walls, this is not EU.
Have you ever used Aircrack-ng suite and some gnu/linux wireless pentesting distro?
You can attach high gain directional antenna to 2000mW wireless card(Alfa brand for instance) and use software tweaks.
Ranges are much higher than you would anticipate.
About Chromecast setting security - yes it is ridiculous.
It asks if you see XYZ9 on a screen. (always click yes - right?)
It should at least ask for some automatically generated password that is visible on the screen...
So for now we may create additional wireless network/VLAN with max one client and connection restrictions...

mathorv said:
Have you ever used Aircrack-ng suite and some gnu/linux wireless pentesting distro?
You can attach high gain directional antenna to 2000mW wireless card(Alfa brand for instance) and use software tweaks.
Click to expand...
Click to collapse
Yes many times and the loopholes you suggest in your scenario are not limited to the Rooted version at all...
Sure there are extra tools in the rooted version that do not exist in the non-rooted....
But the scenario suggested gives you about 30 seconds to get what you want before the router is back up, CCast re-connects and shuts down your session!
And they still have the problem of how to shut down your router or know when it will happen to start working the hack.
Sure someone could probably get what they want in that timeframe..
But someone that good really is not going to be interested in hacking YOU!
Not Unless your some Cartel leader or Bank Executive.
People who have no business rooting anything if they want security....LOL

Asphyx said:
Yes many times and the loopholes you suggest in your scenario are not limited to the Rooted version at all...
Sure there are extra tools in the rooted version that do not exist in the non-rooted....
But the scenario suggested gives you about 30 seconds to get what you want before the router is back up, CCast re-connects and shuts down your session!
And they still have the problem of how to shut down your router or know when it will happen to start working the hack.
Sure someone could probably get what they want in that timeframe..
But someone that good really is not going to be interested in hacking YOU!
Not Unless your some Cartel leader or Bank Executive.
People who have no business rooting anything if they want security....LOL
Click to expand...
Click to collapse
@but someone that good really is not going to be interested in hacking YOU!
World is full of sick people, besides, over the years it has become easy, primary school kid can do it, every hacking soft has a GUI now
@ features - it would be nice to override wifi from panel - sometimes chromecast indicates connecting status. at the same time is connected to secure wifi and has open configuration wifi.
@ alpha builds, I would be glad to flash anything newer that does not totally brake chromecast and is safer for now

Is web panel risky?
Sorry it's even worse:
1. connect to device if its in open network AP state
2. http://192.168.255.249/?page=debug
3. cat /data/wifi/wpa_supplicant.conf
4. SEND
Gone in less than 30 seconds.

mathorv said:
Sorry it's even worse:
1. connect to device if its in open network AP state
2. http://192.168.255.249/?page=debug
3. cat /data/wifi/wpa_supplicant.conf
4. SEND
Gone in less than 30 seconds.
Click to expand...
Click to collapse
Good thing devices only are in AP mode for setup. Besides, once the new web panel is released, this will be a non issue.

Making Rooted safer than Stock

Dear Team Eureka there is one thing you may do with security of Chromecast that Google did not.
You may add the missing security feature:
"if there is no connection to preset network" - "do not enable unprotected wifi ap mode" unless user will press reset button for short time (something like enable/disable wifi feature with openwrt)
There is plenty of things you ma use button for in future
(you may use different functions within different interval)
press
1-5 seconds
6- 15... and so on

I like this feature!

I agree that the way it is currently working is not as secure as it could be...
But I think the better way to do all of this is the following:
1 - Never have the CCast automatically connect to an Open Wireless unless specifically told to via Setup (not sure if it does this now or not)
2 - (and this would be the alternative to your suggestion) CCast doesn't leave any unprotected network sans AP connection for setup. It's default setup mode is a protected WiFi either WEP or WPA
CCast should instead set a random pin/pass and WPA/WEP connection for use in setup when it can't find an authorized AP.
Since you should have access to the screen it is plugged into and hackers would not, you would make the connection to the CCast in protected mode using the PIN that is displayed on the screen to make the connection to the protected network. Once connected you set up the device normally.
Much better than walking over to the TV and device to press a button and much more secure because the only way to set up or take over the unit requires access to the TV it is plugged into.
As far as the Button is concerned I would really like to see it used to switch modes and add a DLNA device mode to the custom rom. Unless the ROM could add this feature while still in CCast mode.

Asphyx said:
1 - Never have the CCast automatically connect to an Open Wireless unless specifically told to via Setup
2 - (and this would be the alternative to your suggestion) CCast doesn't leave any unprotected network sans AP connection. It's default setup mode is a protected WiFi either WEP or WPA
CCast should instead set a random pin/pass and WPA/WEP connection for use in setup when it can't find an authorized AP.
Since you should have access to the screen it is plugged into and hackers would not, you would make the connection to the CCast in protected mode using the PIN that is displayed on the screen to make the connection to the protected network. Once connected you set up the device normally.
Click to expand...
Click to collapse
AFAIK Chromecast never does #1 - it won't auto-connect to any AP unless it's already set up.
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Since the serial number is easily accessible on the unit itself and its box, that could be an easy-to-get password, and the 4-character alphanumeric ID shown on the TV could be a secondary confirmation for Setup, not just a convenient way to make sure you're connected to the correct Chromecast (does Google really think/hope there will be that many Chromecasts out there being set up at the same time?).

Also if http will be protected with https also passwords it may be better to config Chromecast wireless options via https/ssh.
Is there any way to implement power save for example trigger via ssh/https?

bhiga said:
AFAIK Chromecast never does #1 - it won't auto-connect to any AP unless it's already set up.
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Since the serial number is easily accessible on the unit itself and its box, that could be an easy-to-get password, and the 4-character alphanumeric ID shown on the TV could be a secondary confirmation for Setup, not just a convenient way to make sure you're connected to the correct Chromecast (does Google really think/hope there will be that many Chromecasts out there being set up at the same time?).
Click to expand...
Click to collapse
Thats why I think whenever it can't find an AP to connect to it shouldn't take anything for it to generate a random password (changes everytime) that can be used until setup is complete...
As for HTTP access i it is not connected to an AP there really is no HTTP available until you have connected to it in some way.
I would be happy if Google allowed us some config tools but I don't think they are all that interested in us having control over the unit for DRM purposes.
The devs at Plex have even said that Google will not allow them to implement sending to CCast as part of their Local PlexWeb (Plex.TV is fine though)
This suggests they really do not want anything they can't approve or any usage that could expose how the device is talked to being left open to the public.
I guess they figure that if we can see how linkage and communication is done we will reverse engineer it to play and do things they don't want us doing or bypassing DRM schemes as they currently work.

bhiga said:
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Click to expand...
Click to collapse
WEP is broken for over 10 years now! No sane human being is using it. Cracking WEP is extremely fast and easy. WEP is a false protection, illlusion of security. Using WEP is BLASHEMY.

mathorv said:
WEP is broken for over 10 years now! No sane human being is using it. Cracking WEP is extremely fast and easy. WEP is a false protection, illlusion of security. Using WEP is BLASHEMY.
Click to expand...
Click to collapse
Obviously you feel strongly about WEP.
I'm not going to argue that, because you are right that WEP is easily broken. WPA can be broken too, but with more effort.
That said, WEP is an illusion of security only if you expect it to be unbreakable, just like passwords and everything else.
Seat belts won't save you in every accident, but if you don't expect them to, they are still helpful in the event of an accident.
Now if you're driving recklessly because you think seat belts and air bags will save you, then yes it is a false sense of security and you're foolish to take extra risks.
But for the Chromecast setup AP that is temporary by nature, are you suggesting that it is better to not use any security at all, just as it is right now?

You know what I always say.....
"Just because you are Diagnosed Paranoid doesn't mean people aren't out to get you!"
LOL
This is the second conversation regarding CCast vulnerability and so far all we have identified as a REAL security concern is that someone could set up the CCast to connect to some WiFi other than yours which would lead to the grand total tragedy that they could send content to your TV.
The other conversation was in regards to the Rooted ROM having SSH and Telnet installed that could be used to hack your Router Password provided you had already hacked the router password to make the connection to the CCast in the first place to use those tools to get what you already have!
Here is something folks should take into account....NOTHING IS SECURE EVER!
Even the Servers in Iran's Nuke Plant that had no connection to the outside world whatsoever were compromised, Hacked and attacked by Stuxnet!
There is no security ever the only thing you can ever really do is make the hack hard enough and as time consuming as possible that they will move onto someone else's system to pry into their Word Docs and that private folder you keep your IFriends profile pictures in instead. LOL
Yes WEP can be hacked. Imagine how much fun someone will have after they set up your CCast to use their network and try to send content to a TV never knowing if you actually noticed it or not because they can't see your TV.
It's still a damn site better than leaving an Open WiFi AP on the CCast until setup which takes no hacking skill at all to crack.
The way I look at it if the person is smart enough to hack they are also smart enough to know there is no point in hacking a CCast...Not when there is a WiFi router that gets them a hell of a lot more personal info and much more access than just displaying content to your TV.

Asphyx said:
This is the second conversation regarding CCast vulnerability and so far all we have identified as a REAL security concern is that someone could set up the CCast to connect to some WiFi other than yours which would lead to the grand total tragedy that they could send content to your TV.
Click to expand...
Click to collapse
While this would be a great dorm prank, at least with the current functionality of Chromecast, that's all they get to do... turn on the TV and send whatever video to the TV they want, which would be quite scary/annoying. Think of the beginning of Back to the Future Part II where all the screens in the house turn on with Marty's boss telling him he's fired.
Asphyx said:
The other conversation was in regards to the Rooted ROM having SSH and Telnet installed that could be used to hack your Router Password provided you had already hacked the router password to make the connection to the CCast in the first place to use those tools to get what you already have!
Click to expand...
Click to collapse
Actually I think the scenario @mathorv described is a little different and easy to exploit.
Chromecast is in setup mode and broadcasting an open AP
Attacker connects to the open AP
Attacker connects to Web Panel and enables ADB/Telnet/SSH (because web panel currently does not require authentication, Team Eureka said authentication is coming)
Attacker connects to Chromecast via ADB, Telnet, or SSH and gets access to the root filesystem, where they can see the cleartext password and SSID of the AP that Chromecast normally connects to (because password is stored in supplicant config file which is accessible)
So the attacker does not need anything more than to see the Chromecastnnnn AP.
Sadly, the WPA authentication seems to be stored the same way on phones/tablets as well. The only thing that shields phones/tablets from the same type of attack is not all of them have root and they usually aren't accessible from the network. Hence, with root comes extra responsibility, which is why root often is made difficult.
Asphyx said:
Here is something folks should take into account....NOTHING IS SECURE EVER!
Click to expand...
Click to collapse
Yup. What we commonly call "security" is really just a deterrent. It increases the effort and the hope is that the attacker will pick an easier target. It's why we put locks on doors when it's often relatively simple to bypass them.

bhiga said:
Chromecast is in setup mode and broadcasting an open AP
Attacker connects to the open AP
Attacker connects to Web Panel and enables ADB/Telnet/SSH (because web panel currently does not require authentication, Team Eureka said authentication is coming)
Attacker connects to Chromecast via ADB, Telnet, or SSH and gets access to the root filesystem, where they can see the cleartext password and SSID of the AP that Chromecast normally connects to (because password is stored in supplicant config file which is accessible)
So the attacker does not need anything more than to see the Chromecastnnnn AP.
Click to expand...
Click to collapse
Except for the fact that if it is not connected to the router then that means the router is unavailable, and or the Password saved in cleartext isn't working. If it was it would be connected and not in Setup mode.
Thats the point I was trying to get across there....
Sure you could find passwords to APs the CCast was connected to...
But if it isn't connected at the time of the hack then those APs are not available if they were you would not be able to connect to the CCast.
And if they are available then anything saved in the CCast is worthless since the CCast couldn't use it to connect either.
And I told him how to plug that hole far better than via the ROM....
Turn on Mac Filtering so not only do you need the password but need to clone a MAC address as well.
And all of this to get at what?
Your last will and testament and some compromising Pictures?
If you make it difficult enough that the payoff isn't worth the effort they will move on....

Asphyx said:
Except for the fact that if it is not connected to the router then that means the router is unavailable, and or the Password saved in cleartext isn't working. If it was it would be connected and not in Setup mode.
Click to expand...
Click to collapse
Ahh, I see your point now.
At least for me, sometimes Chromecast will "miss" the connection shortly after boot, so the setup AP is available for a few minutes after a reboot. To exploit that, someone would need to be sitting and listening for it to pop up - not a "juicy" target, but still possible. People do strange things "just because they can" - at least that's what YouTube teaches me.
As you say, MAC filtering provides an additional deterrent level. Unfortunately the target customer is probably not sophisticated enough to do that. I'm not sure all ISP-provided devices (I avoid integrated hardware that I can't configure) allows setting MAC restrictions though.

Asphyx said:
But if it isn't connected at the time of the hack then those APs are not available if they were you would not be able to connect to the CCast.
And if they are available then anything saved in the CCast is worthless since the CCast couldn't use it to connect either.
Click to expand...
Click to collapse
Well, in theory, you could connect to the CCast when it is in unprotected AP mode, enable ssh, and write a shell script which gets started every boot and sends out the saved wifi password somewhere to the internet. Then, when the CCast owner sets up is wifi, and sometimes later reboots, the wifi passwords will be sent out.
But... since there are probably only a few thousand rooted Chromecasts, and the time window in which to push the script to the Chromecast is so narrow, I doubt anyone would spend any time to try this.

bhiga said:
Unfortunately the target customer is probably not sophisticated enough to do that. I'm not sure all ISP-provided devices (I avoid integrated hardware that I can't configure) allows setting MAC restrictions though.
Click to expand...
Click to collapse
I'm sure thats true but if your not sophisticated enough to control your own Network or let an ISP do it all for you the least of your issues are what might happen in the odd chance CCast is disconnected or in the 30 seconds before it connects to an AP during Bootup. Locking up the holes in a CCast sure isn't going to help you much LOL
frantisek.nesveda said:
Well, in theory, you could connect to the CCast when it is in unprotected AP mode, enable ssh, and write a shell script which gets started every boot and sends out the saved wifi password somewhere to the internet. Then, when the CCast owner sets up is wifi, and sometimes later reboots, the wifi passwords will be sent out.
Click to expand...
Click to collapse
Well in theory you could have it do location checks with Google and map location, SSID and Password of every AP it ever connects to...
Like I said to what end would someone do that?
What is the PAYOFF in the end?
I could understand it if your living next to Bill Gates and wanted to steal banking info....
The Average Joe doesn't have anything worth seeing that would make someone go through all of that especially when they could get it much easier by just sniffing WiFi packets and finding the same data and decrypting it.
They could sit there all day and hack the Router but they have such a small window to work with on an unconnected CCast either because they have to catch it rebooting or catch it in a location that it isn't setup for and unless you have written a program to do all of that without Human Intervention you still got a snowballs chance in hell of getting any worthwhile information...
Security only happens when there are multiple layers of protection that make it so difficult to breach that they won't bother unless the payoff is worth it.
Someone really has to hate you in order to go through all that so some of the best security practices you can implement is don't be an AZZ and no one will have it out for you enough to want to get something on you via a Hack! LOL
(Not suggesting anyone in this discussion is just saying in General LOL)

Asphyx said:
Like I said to what end would someone do that?
Click to expand...
Click to collapse
Well, would you give me your WiFi password?
I can think of a few things you could do with access to someone's WiFi... Free internet, torrenting on someone else's responsibility, or just messing with someone.
Asphyx said:
I could understand it if your living next to Bill Gates and wanted to steal banking info...
Click to expand...
Click to collapse
The real question here is... Would Bill Gates buy a Google Chromecast? :laugh:

frantisek.nesveda said:
Well, would you give me your WiFi password?
I can think of a few things you could do with access to someone's WiFi... Free internet, torrenting on someone else's responsibility, or just messing with someone.
The real question here is... Would Bill Gates buy a Google Chromecast? :laugh:
Click to expand...
Click to collapse
Sure! I could very easily give you my router password and you would still not be able to do anything you mentioned until you figured out a MAC address one of my networked devices actually uses.
And to my other point...Is Free Internet or messing with someone really worth the risk of going to a Federal Pen for hacking?
As for what Bill Gates has I wonder if he is even running Windows 8 cause I don't know anyone who has it that likes it! LOL

Asphyx said:
Sure! I could very easily give you my router password and you would still not be able to do anything you mentioned until you figured out a MAC address one of my networked devices actually uses.
Click to expand...
Click to collapse
Good point.
I guess that if we really wanted, we could play this cat and mouse game for quite some time, but the outcome would be that if you really care about security, you can make your network secure enough. But that would be just spamming the thread.

frantisek.nesveda said:
but the outcome would be that if you really care about security, you can make your network secure enough. But that would be just spamming the thread.
Click to expand...
Click to collapse
Actually I think what I was trying to say is that no matter how much you care and try to be secure...
If they want you they WILL get you and they don't need nor would they do it through your CCast when there are far better tried and true methods to attack a wireless router directly that doesn't require LUCK of a device not connecting or the timing of catching it while it is booting up in order to catch the weakness.
Any security hole that results from the CCast will likely never amount to anything more than the Prankish "Look what dirtyPorn I put on your screen"
If they want dirt they will go to the router which is always up and doesn't require some act of god or electronics to happen.
You secure your router the best you can and if that isn't enough then you need to keep your wireless off until you need it to be TRULY secure....
And even then there is nothing to stop them from tapping into the pole where your Internet connection comes in and getting you that way!
Security is nothing more than an illusion and a deterrent...Truth is your never secure no matter how much you worry which says to me...Worrying is pointless. Unless you have enemies that really want to get you...and if thats the case all the security in the world won't stop them!

Asphyx said:
Actually I think what I was trying to say is that no matter how much you care and try to be secure...
If they want you they WILL get you and they don't need nor would they do it through your CCast when there are far better tried and true methods to attack a wireless router directly that doesn't require LUCK of a device not connecting or the timing of catching it while it is booting up in order to catch the weakness.
Any security hole that results from the CCast will likely never amount to anything more than the Prankish "Look what dirtyPorn I put on your screen"
If they want dirt they will go to the router which is always up and doesn't require some act of god or electronics to happen.
You secure your router the best you can and if that isn't enough then you need to keep your wireless off until you need it to be TRULY secure....
And even then there is nothing to stop them from tapping into the pole where your Internet connection comes in and getting you that way!
Security is nothing more than an illusion and a deterrent...Truth is your never secure no matter how much you worry which says to me...Worrying is pointless. Unless you have enemies that really want to get you...and if thats the case all the security in the world won't stop them!
Click to expand...
Click to collapse
MAC access list = joke, blacklist is also a illusion changing MAC address(spoofing MAC) is extremely easy on any platform.
In case of whitelist Attacker will look into it just a bit for a longer, to know list of allowed devices.
At home you will have to whitelist every new device...
In corporate environment it will take you more time also WPA2-PSK is not suitable for serous corporate use.
About absolute security.
Security is relative term. Its just like healthy life style, it will not make you immune to diseases, it will make you generally healthier, less likely to get ill.

Google Play Music Disconnecting When Idle

I just wanted to make a thread to see if anyone else was experiencing an annoyance I've been dealing with for the past few days. I don't know if it's due to a new firmware version on the Chromecast, or the recent update to the Play Music app, but casting music hasn't been such an intuitive experience for me recently. As a relevant note, both my Chromecasts are running the latest Eureka-ROM.
As long as I've had the Chromecast, casting music from Play Music has been fluent and the connection between the Chromecast and my HTC One was hard to break, even as I switched between apps and let my phone go to sleep. Recently, this hasn't been the case. If I am listening to an album on the Chromecast while tethered to my phone, I may pause it for a number of reasons and step away, then come back and expect to resume it. When I pause the song, then walk away, my phone will obviously go to sleep (since my screen timeout is 1 minute). As of the last few days, when I return to my phone after such a break, I look at my TV and find my Chromecast back at the homescreen. I then look at my phone and the Play Music app thinks it is still connected and the song is paused. When trying to press play a dialog pops up and says something along the lines of "The song cannot be played at this time." The only way to resume playback is to click "Disconnect" in the app, then reconnect and it goes back to normal once I restart the song.
So anyway, I suppose this may be a Eureka-ROM thing, but I don't see the reasoning behind that line of thinking. Has anyone else been experiencing this or any other change of behavior in Play Music?

Just to make sure, double-check your Keep Wi-Fi on during sleep setting.

bhiga said:
Just to make sure, double-check your Keep Wi-Fi on during sleep setting.
Click to expand...
Click to collapse
I could see that helping to keep control but if GPlay is working correctly he shouldn't have to be connected to the CCast with his device at all...
Does GPlay Music work differently than everything else does?

Asphyx said:
I could see that helping to keep control but if GPlay is working correctly he shouldn't have to be connected to the CCast with his device at all...
Does GPlay Music work differently than everything else does?
Click to expand...
Click to collapse
Many of the playlist-enabled apps have some level of "ping back" to manage the playlist functionality if it's not handled server-side.

bhiga said:
Many of the playlist-enabled apps have some level of "ping back" to manage the playlist functionality if it's not handled server-side.
Click to expand...
Click to collapse
Ahhh OK that does make some sense since no one seems able to do a proper playlist on the CCast that I have found...
Not the way it should work but I guess thats the workaround.
Google really should address this somehow...

Asphyx said:
Ahhh OK that does make some sense since no one seems able to do a proper playlist on the CCast that I have found...
Click to expand...
Click to collapse
The alternative would be to maintain a queue at the server's end, like how YouTube does TV Queue. Problem is, when interfacing with locally-hosted media it raises some privacy issues as the location leaves your network. It also would incur Internet traffic for those on limited/paid connections, albeit tiny, it'll still add up.
And of course not every app has a login/server attached to it. Perhaps something could be rigged with a cloud-hosted playlist file or something via Google Drive or another location that Chromecast can directly access.

bhiga said:
The alternative would be to maintain a queue at the server's end, like how YouTube does TV Queue. Problem is, when interfacing with locally-hosted media it raises some privacy issues as the location leaves your network. It also would incur Internet traffic for those on limited/paid connections, albeit tiny, it'll still add up.
And of course not every app has a login/server attached to it. Perhaps something could be rigged with a cloud-hosted playlist file or something via Google Drive or another location that Chromecast can directly access.
Click to expand...
Click to collapse
Or you could send the app a playlist of links to play one after the other...
Sort of the way the old ASF files used to work.

Asphyx said:
Or you could send the app a playlist of links to play one after the other...
Sort of the way the old ASF files used to work.
Click to expand...
Click to collapse
I think some of the apps have moved to that buffered playlist model, though it still requires some callback and housekeeping in case the controller changes the playlist, etc.

bhiga said:
I think some of the apps have moved to that buffered playlist model, though it still requires some callback and housekeeping in case the controller changes the playlist, etc.
Click to expand...
Click to collapse
I suppose...But they could allow changes via the control channel if they fleshed that channel out....
It definitely is one of the things Google has dropped the ball on in their design.

Thanks for the responses guys! Yeah, my Wi-Fi sleep policy is set to "Always", so that's not the issue. It's weird, my CCs have also not been showing up at all until a reboot sometimes. Something in the new GMusic or new CC firmware is not working as well as it used to.

For the sake of being thorough, give your router a reboot if you haven't already.
Also, do a ping test on your network to ensure it's not a faulty router/switch. I recently had to replace a switch (under lifetime warranty, luckily) because it had silently gone bad. It was still passing some traffic - enough for me not to notice immediately, but then my server lost its Gigabit connection (would only connect at 100 Mbps) and that got me investigating more.

bhiga said:
For the sake of being thorough, give your router a reboot if you haven't already.
Also, do a ping test on your network to ensure it's not a faulty router/switch. I recently had to replace a switch (under lifetime warranty, luckily) because it had silently gone bad. It was still passing some traffic - enough for me not to notice immediately, but then my server lost its Gigabit connection (would only connect at 100 Mbps) and that got me investigating more.
Click to expand...
Click to collapse
That probably has a lot to do with it, now that you mention it. My AP is a crappy Linksys and I experience random connection drops occasionally. I've been meaning to replace it with something better for a while. I just power cycled it and I am casting fine now. I also paused a song and gave it a few minutes without touching my phone and it resumed alright. Then ten seconds later the song started back from the beginning. Since this isn't a known problem it probably is dropped packets from my AP or something similar.

Synthic said:
That probably has a lot to do with it, now that you mention it. My AP is a crappy Linksys and I experience random connection drops occasionally. I've been meaning to replace it with something better for a while. I just power cycled it and I am casting fine now. I also paused a song and gave it a few minutes without touching my phone and it resumed alright. Then ten seconds later the song started back from the beginning. Since this isn't a known problem it probably is dropped packets from my AP or something similar.
Click to expand...
Click to collapse
If your AP is dropping out that can cause a number of problems. Is it one of the older WRT54G models? I used to run a bunch of those but there's a logging bug (even with logging turned off) that causes the router to go haywire. The third-party firmwares fixed it by flushing the logs via a cron job or firewall rule, I believe. I ended up with a pile of them after I moved to Pogoplugs for my VPN endpoints/servers.

bhiga said:
If your AP is dropping out that can cause a number of problems. Is it one of the older WRT54G models? I used to run a bunch of those but there's a logging bug (even with logging turned off) that causes the router to go haywire. The third-party firmwares fixed it by flushing the logs via a cron job or firewall rule, I believe. I ended up with a pile of them after I moved to Pogoplugs for my VPN endpoints/servers.
Click to expand...
Click to collapse
That's interesting, I never knew that. I did actually used to have a WRT54G, but have since upgraded to a EA2700. I was playing around with the settings and I switched it over to "bridge mode" which I think fixed the issue. I use a router provided by Comcast so the Linksys was supposed to be acting strictly as an AP but it wasn't. Any casting I've done since has been working well.

Invalid teleservice ID error when trying to send SMS or MMS

I recently bought a Verizon Note 9 (first Samsung phone) so I'm not well versed on things. I have noticed from time to time when I am not receiving carrier signal (still connected to wifi) my texts will start failing with the error "Invalid teleservice id".
After some digging I noticed that my phone number in "About Phone" was incorrectly set to an invalid number 1-265-000-000.
I have cleared all caches and reset all settings I can think of. This problems occurs on all SMS applications. So far I have tried: Google Messages; Samsung Messages; Verizon Messages+.
Where does the "About Phone" page get populated from?
My hunch is the internal number of the phone is getting set by some screwy logic and that is throwing off everything that relies on it.

Invalid teleservide id soulution found
I need people to test this solution to make sure it works across all devices as the error seems to affect all android devices under certain conditions. If you would like to read how I came to this solution to help me check my work or you are just interested please keep reading, If you just want the solution feel free to skip to the bottom paragraph beginning with SOLUTION. If you try this solution, which I actually believe to be a solution and not a hotfix, please respond with 3 pieces of information: 1) Did it work. 2) What Android device you use and the version of Android you are using and 3) Your ISP (Internet Service Provider).
This data is very important.
STORY:
So, last month I switched to Android for a couple of reasons after having used iPhones since the iPhone 5. The two most important things to me were being able to stream music using the LDAC Bluetooth codec and having a crack at Samsung Dex to see if I could avoid buying a laptop next year. I was immediately happy with these features that had been the impetus for switching, but then something unexpected happened: the thing that I have always taken for granted, i.e. my phone sending/receiving calls and texts, was incredibly unreliable on this phone (Galaxy S20 Ultra). After doing some googling and finding the official forums (there seem to be 2 devoted to this issue and I will post this both places) I found the incredibly disheartening ‘hotfix’ of disabling WiFi calling to be completely unnaceptable. Not only because I don’t actually get cell service in my apartment but because a $1400 flagship smartphone should certianly not have less functionality in any area that an iPod Touch circa a decade ago.
Normally I would just take my faulty device down to a Verizon store because although I am in IT I specialize in computers more than phones, however since we have been in isolation this began an approximately 20 hour saga via the phone over the span of May 25th to June 19th. After trying everything I could glean might work from google, and following every step that Verizon tech support asked me to try and actually convincing them to update the carrier settings on my account I was finally given the OK to get a replacement device. It is important to note at this point that I had only been searching this error for my model phone and mistakenly had the idea that it was an incredibly rare issue that was a problem with a select few devices.
So, you can imagine my complete and udder shock after getting the replacement phone, setting it up, and getting the Invalid Teleservice ID Error 4 on the second text message I tried to send on the device. It took me about an hour to really get my wits together because at this point I was trying to come to terms with the very possible reality that I was not going to be able to use my phone at home reliably because I don’t have good reception over WiFi. When my faculties returned, I resolved to read every post I could find on this issue.
What I found is that this problem has been around since certain people started installing Android 8 on their phones and that they have been trying to get Verizon to offer an actual solution since 2017. So here we are 3.5 years later and almost 4 generations of Android later and “the best network” has so far failed to offer any sort of real solution to this problem. However, from getting the error on my new phone and seeing that the error was effecting essentially every model device Verizon sells (that runs Android) gave me a key piece of data: the problem has nothing to do with the device.
After getting deeper and deeper into some forums I noticed that one person reported that this problem only occurs for them when they use an Xfinity WiFi hotspot. That was my lightbulb moment. I am also an Xfinity customer. I then started searching the problem from that perspective and found that most of the people reporting the error and mentioning their ISP were either Xfinity or Spectrum customers, and now I was starting to feel like I might be onto something.
In terms of IT, networking is my weakest area. Nevertheless I dove into some forums that have tried to approach this problem from a networking perspective and although a lot of it was over my head I started to suspect there was something about the firewall on Xfinity and Spectrum routers that is causing the problem. After 72 hours of exhaustive testing ( not only is 24 hours approximately my previous record for not having the error, but I used that time to send out as much information via text messaging as possible to try to cause the error) I am ready to posit a hypothesis as to what is actually causing the problem and post the solution that is currently working for me.
As I have noticed that the problem is most likely to crop up for me when I am using Dex and a physical keyboard and have tried to send many texts in quick succession, the idea came to me that somehow trying to send a large volume of data exacerbates a problem that Xfinity and Spectrum routers have reliably delivering packets in the right order and format over the internet to the Verizon network. So, this is what I decided to try, and it has now worked for approximately 84 hours straight and has performed flawlessly under stress testing (Spamming 500 word texts and hi res photos to multiple people in quick succession using copy/paste).
SOLUTION:
I’m sure many of you who play video games have used a function on your routers to get around NAT issues called the DMZ. The DMZ allows you to put a device using a specific IP address on your personal network outside of the firewall and connect it directly to the internet. For a device that exists on this network wirelessly there is a simple step you must take first. You must assign your device a static IP. If you go into your router settings you will likely find that all devices on your network are assigned IP addresses via a system called DHCP. This essentially means your device will probably have a new IP every time you leave the house and return, so we need to make it the same every time so that the DMZ will function the way we want it to. Every router is going to have a slightly different settings menu, but you should be able to find a tab that lists the CONNECTED DEVICES on your network. What you need to do is change your phone from being a DHCP connected device and assign it a STATIC IP address. Finding the option to do this may be harder than actually doing it, all you need to do when you find the option is change the connection type from DHCP to Static and pick and IP address that will work for you. My network uses 10.0.0.XX for the devices on my home network so I assigned my phone to 10.0.0.99. Then I placed the 10.0.0.99 in the DMZ. In my router menu, the DMZ is under ADVANCED SETTINGS and when you select the DMZ tab, simply enter the IP address you chose for your phone.
To recap:
1) Set your phone to a static IP
2) Put that IP in the DMZ
That’s it. A valid criticism of this solution is that your phone is less secure, however I would respond that the likelihood of your phone being hacked is much smaller that that of a PC and if this slightly loosened security really bothers you, just use a VPN. A VPN will keep you safe in a Starbucks on their free public WiFi and it can protect you here (I actually had a VPN when I got my device and originally I thought it was the cause of the Invalid Teleservice error). CAUTION: There has been a crop of predatory VPN services lately that provide working VPNs, but will charge you a ridiculous amount. I use NordVPN (I found a code on YouTube that gave me 70% off six devices on a 3 year plan, that ended up costing about $100) but there are plenty of good services that will allow you to connect to the internet via a VPN on one device for approximately $2-3 a month.
So please, try this and report back. This error has been the bane of my existence since switching to Android and it is completely unacceptable that Verizon has had literally years to do figure out a solution to this problem and yet they have not. My end goal is not to receive credit but to make sure that in the future Verizon Tech Support actually knows how to help people solve this problem, and their techs don’t take your calls and then look the problem up on google, proceeding to be completely transparent in terms of having no actual knowledge of this issue and literally reading the same forums I have already been over and suggesting the non-solutions posted there in order, i.e. turn off WiFi calling and if that doesn’t work turn off ‘Advanced Calling’.
REMEMBER: If this solution does not work for you, please double check that your changes the router you use have stuck. I have previously had routers that will for reasons I don’t understand change the DMZ domain or switch a device back to DHCP from static or simply fail to save your changes properly.
I await responses eagerly.

You need to take your device to your local high street retail branch of your cell provider and ask them to check your SMS/MMS settings

I would love to be able to actually go into a brick and mortar Verizon store but that's currently not possible in WA state. I had to have a tech walk me through checking those settings myself (after doing my own research as well) and had somebody at level 3 of tech support at Verizon manipulate my carrier settings. That's pretty much all I can do during the pandemic.
My solution is still working for me though, however 33 min after I put the same post on the official Verizon forum they closed the thread which had had regular posts over the last 3 years so now I'll never know if it works for anybody else. Additionally, there was somebody on the forum who approached the problem from SMS/MMS settings perspective and it had to do with deleting server settings and whatnot. It was so complicated that I doubt many end users could follow the same steps.

K_A_Beausoleil said:
I would love to be able to actually go into a brick and mortar Verizon store but that's currently not possible in WA state. I had to have a tech walk me through checking those settings myself (after doing my own research as well) and had somebody at level 3 of tech support at Verizon manipulate my carrier settings. That's pretty much all I can do during the pandemic.
My solution is still working for me though, however 33 min after I put the same post on the official Verizon forum they closed the thread which had had regular posts over the last 3 years so now I'll never know if it works for anybody else. Additionally, there was somebody on the forum who approached the problem from SMS/MMS settings perspective and it had to do with deleting server settings and whatnot. It was so complicated that I doubt many end users could follow the same steps.
Click to expand...
Click to collapse
Thanks for your efforts. I've had this same issue on my Note 9 for 2 years... Your solution did not work for me.
However, I found a solution this morning. My ISP is not Xfinity or Spectrum. But my network which is spread across a small community blocks some IPsec ports that are required for wifi calling. Enabling those ports on my router does not fix the problem since it is a network/modem setting that I don't have access to.
What does work is having a vpn profile that implements IKEv2/IPsec VPN tunnels on your Android device. I have a NordVPN subscription and downloaded the StrongSwan VPN client from the Play Store. This client only uses IPsec encryption. Using a NordVPN server that has this encryption with the StrongSwan VPN client has allowed me to bypass this network restriction and my wifi calling phone calls and texts go through just fine now.
Hoping this helps someone else...
---------- Post added at 04:37 PM ---------- Previous post was at 04:05 PM ----------
hkjxda said:
Thanks for your efforts. I've had this same issue on my Note 9 for 2 years... Your solution did not work for me.
However, I found a solution this morning. My ISP is not Xfinity or Spectrum. But my network which is spread across a small community blocks some IPsec ports that are required for wifi calling. Enabling those ports on my router does not fix the problem since it is a network/modem setting that I don't have access to.
What does work is having a vpn profile that implements IKEv2/IPsec VPN tunnels on your Android device. I have a NordVPN subscription and downloaded the StrongSwan VPN client from the Play Store. This client only uses IPsec encryption. Using a NordVPN server that has this encryption with the StrongSwan VPN client has allowed me to bypass this network restriction and my wifi calling phone calls and texts go through just fine now.
Hoping this helps someone else...
Click to expand...
Click to collapse
Scratch this... Wifi calling uses it's own IPsec VPN tunnel, VPN clients only encrypt internet traffic, not cell service. Back to square one...