Database Develop

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.

Wired warns of Chromecast takeover vulnerability

"Rickroll Innocent Televisions With This Google Chromecast Hack"
http://www.wired.com/2014/07/rickroll-innocent-televisions-with-this-google-chromecast-hack/
In short the video shows:
- remote device forces disconnect of Chromecast by sending deauth command over WiFi
- Chromecast reverts to Reconnect Me mode with its own WiFi
- remote device connects and takes over Chromecast
But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?
The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.

DJames1 said:
"Rickroll Innocent Televisions With This Google Chromecast Hack"
In short the video shows:
- remote device forces disconnect of Chromecast by sending deauth command over WiFi
- Chromecast reverts to Reconnect Me mode with its own WiFi
- remote device connects and takes over Chromecast
But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?
The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.
Click to expand...
Click to collapse
Hey! This is Dan, the researcher behind the story. To answer some of your questions:
The "access code" that the Chromecast shows is never actually used to authenticate people on the Wi-Fi. its only purpose is to make sure users don't accidentally connect to their neighbor's chromecast on accident. You can verufy this yourself: If you go into the Chromecast Android app and reconfigure your own Chromecast, you'll see that the app pops up with a message that says "Do you see the code 'X1B8'" (or whatever). You can just say "yes" and ignore it. The user never has to enter and verify the code itself.
As for the buffer overflow, it's true that there's no good evidence of it yet. I just haven't finished exploiting the vulnerability. Until I actually have a working exploit, there's no way to be sure that it really exists. The buffer overflow for sure exists, and it's in a remotely accessible location. But who knows, maybe there's some other wrinkle that keeps it from being exploitable. Exect to see more on that soon.
Hope that helps!

yep that PIN system they have is a pretty useless one considering it is more of a CHECK than a security feature....
If it was like a BT PIN where you had to enter the pin you see on the screen before you could connect it would be a real security system.
I wonder why Google hasn't thought of that,

Yup, any Chromecast is vulnerable to "takeover" whenever it gets disconnected from its configured WiFi AP.
Why? Because its setup mode is completely open and requires no challenge, just a response. It's like if you call a credit card company, put in a number that isn't yours, then the agent comes on the line and asks
"Are you Joe Smith?" [Yes]
"Is your password 'ChocolateMilkGivesMeGas'?" [Yes]
Because a simple reconfiguration does not seem to delete the existing WiFi supplicant data (Google could easily fix this by erasing the stored WiFi credentials once a device connects for setup), if the noted buffer overrun bug or another exploit could gain root, user's WiFi credentials are easily accessed.
Factory reset does delete the stored WiFi credentials, but nobody's going to factory-reset their Chromecast until it's already too late.
This particular issue is an issue for those running rooted Chromecasts, as all the attacker needs is a way in (which includes the Team Eureka Web Panel for those running Eureka-ROM, as the current web panel is not secured).
IMO, Google needs to make the setup more secure - ease of use should never data trump security.

Ah, so it's not an access code, it's just an ID to help you match up the Chromecast the app sees on WiFi with the one you see on the TV screen. That certainly seems insecure, especially since there are so many other devices and apps that link up securely via a very similar-appearing access code.
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.

DJames1 said:
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
Click to expand...
Click to collapse
Yeah, Google seems to think being on the WiFi network is "secure" enough and anything else public/school/hotel is not the place for Chromecast... that logic may work in a single-family living situation, but it definitely does not work in a shared environment, and the fact that it automatically goes into Setup mode when it loses its configured AP is where the risk lies, since someone can reconfigure it to connect to their WiFi network and it still has the original user's AP credentials stored.
Google can lock things down by changing the behavior so either
Clear the stored WiFi credentials when the setup process begins, before Chromecast connects to another network
This wouldn't stop some kind of remote-access exploit that can break in during setup mode, but it does stop any normal-mode exploits.
Require a factory reset to enter Setup mode when Chromecast is configured to connect to a WiFi network.
IMO the second one is more of the expected user behavior - when it arrives it has no credentials stored so it automatically proceeds to setup mode, but once configured it stays configured and requires reset to start configuration again.
Right now it says configured but can be reconfigured - by anyone any time the configured AP goes unavailable.

DJames1 said:
Ah, so it's not an access code, it's just an ID to help you match up the Chromecast the app sees on WiFi with the one you see on the TV screen. That certainly seems insecure, especially since there are so many other devices and apps that link up securely via a very similar-appearing access code.
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
Click to expand...
Click to collapse
Yeah if the made the Pin System an integral part of allowing connection then it would be MUCH more secure even if it was in open AP mode because you would still need to be in front of the TV it is plugged into to see the pin!
Odd isn't it how Google seems to have spent so much effort and time into securing what can RUN on the damn device yet took little to no interest in who could connect to it!
The fact that the worst thing possible is a bad Video Picture being displayed I guess they thought it wasn't worth the effort and was maybe too difficult for an idiot to use if it was secure!

Is the fingerprinting really gone on the ZX1 Compact?

Amazon descriptions clearly state no fingerprint function. Is this accurate?
TIA!

@OldSkewler
Nope, it's on the power button.
For the future, I suggest using better information-sources about those devices, like gsmarena or the official Sony device page.
That is, if actually mean the XZ1c, since there's no ZX1 .

Amazon seller, listed as "Sony", clearly states no fingerprinting hence my question.
Any chance they offer a version without fingerprinting feature? I remember when I bought my Z5C that one of the versions didn't offer this feature.

Due to some licensing issues, sony-devices come without fingerprint capability in the US. This is however done software-side, so flashing a firmware from somwehere else than the US will enable the fingerprint reader. This may be the reason for the conflicting statements on Amazon. If the fingerprint reader is enabled, it has to be activated in settings, so you can chose to no use it.

American here. I got one from Amazon and flashed the Central Europe firmware to enable the fingerprint sensor. First phone I got with a biometric sensor!

Interesting.
First I was under the impression these Sony devices were pretty locked and hard to crack, I think this was the case back in 2015. Or maybe there are different levels of "cracking" and firmware updating is fairly simple? I am relatively new to this sort of thing.
Second, I also bought my Z5C from Amazon and fingerprinting was functioning off the box, no issues or need to change firmware.
Perhaps would be easier to purchase on eBay.

It's entirely possible that you bought the international version of the phone instead of the US version. I used the NewFlasher guide in order to get the fingerprint scanner working. I'm on T-Mobile with a European firmware so I don't have wi-fi calling, but I live in Silicon Valley so there's hardly any shortage of good signal for me.

OldSkewler said:
First I was under the impression these Sony devices were pretty locked and hard to crack, I think this was the case back in 2015. Or maybe there are different levels of "cracking" and firmware updating is fairly simple? I am relatively new to this sort of thing.
Click to expand...
Click to collapse
The fingerprint feature is probably the only function that is disabled on an extremely high software level for the sole purpose of being able to officially sell in the US.
Otherwise, your impression of Sony phones is generally correct - while also incorrect at the same time.
Specifically, you'd be right when things involve Sony DRM related stuff.
On the other hand, Sony opens up a lot of their phones for development and contribution to AOSP.
As long as you aren't fixated on retaining DRM locked features, it's actually pretty simple to unlock and mess around with Sony devices (that are on the list).

A bit different question about fingerprint reader. Time after time I get notice "device was locked by administrator" and I need to enter pin as it does not unlock with fingerprint? Is it possible to avoid and always be able to unlock with fingerprint?

martynas said:
A bit different question about fingerprint reader. Time after time I get notice "device was locked by administrator" and I need to enter pin as it does not unlock with fingerprint? Is it possible to avoid and always be able to unlock with fingerprint?
Click to expand...
Click to collapse
I'm guessing you have an app, which locks the screen - check in Settings > Lock screen & security > Device admin apps to see which apps have access to lock the screen, and then just go trial-and-error from there.

BetaLyte said:
I'm guessing you have an app, which locks the screen - check in Settings > Lock screen & security > Device admin apps to see which apps have access to lock the screen, and then just go trial-and-error from there.
Click to expand...
Click to collapse
Thanks! Will try. 2 apps find my device and email exchange. Exchange cannot deactivate. Will see if "find my device" will be enough...

martynas said:
Thanks! Will try. 2 apps find my device and email exchange. Exchange cannot deactivate. Will see if "find my device" will be enough...
Click to expand...
Click to collapse
Nah, I don't think it's Find My Device. I was thinking it could be a lock screen app or a launcher, which could be the culprit, but it doesn't sound like you have any of those.
Exchange could cause this, if your work place has disabled the fingerprint reader as part of their security policy. You can press the icon, and see which policies are enforced. The only work around would be to use IMAP to fetch your mails instead. Or root your phone, and use an Xposed module to disable the security policy, but I wouldn't recommend it, as you would loose your DRM keys, and be left with a non-functional camera.

BetaLyte said:
Nah, I don't think it's Find My Device. I was thinking it could be a lock screen app or a launcher, which could be the culprit, but it doesn't sound like you have any of those.
Exchange could cause this, if your work place has disabled the fingerprint reader as part of their security policy. You can press the icon, and see which policies are enforced. The only work around would be to use IMAP to fetch your mails instead. Or root your phone, and use an Xposed module to disable the security policy, but I wouldn't recommend it, as you would loose your DRM keys, and be left with a non-functional camera.
Click to expand...
Click to collapse
You are right - it was "power toggle" with screen lock option...
But it is still working quite strange. When I disabled power toggle to lock the screen, I actually do not need and fingerprint to unlock device. I can unlock simply by swipe. I thought fingerprint is instead of a pin, not instead of a swipe...
It is a bluetooth watch that is trusted device and does not require fingerprint to unlock...

martynas said:
Thanks! Will try. 2 apps find my device and email exchange. Exchange cannot deactivate. Will see if "find my device" will be enough...
Click to expand...
Click to collapse
eMail Exchange is the culprit.

VPN connected but IP is still transparent

Hi community,
Seeking help here. I have never had any issues with regards to VPN connection on my note 9. I have subscription with CyberGhost VPN however I also have free versions of Thunder VPN and X-VPN.
The issue which occurred today that I cannot fix. I am able to connect using both the paid/free VPNs mentioned above, however once connected, my real IP is still transparent.
When I open the 'key lock' android system VPN management popup, I can see that no data is sent or received even though I have surfed web, watched videos etc. I used ipleak.net to confirm the when connected to VPN my IP transparent.
When I restart the device and connect vpn, it works normally i.e. ip not is transparent. But after some time it automatically becomes transparent again. Power saving is never on. I have to restart device again for VPN to work normally again, albeit a short time.
Anyone encountered similar issue and/or have any solution?

I am having the same issue as well, first everything worked fine and suddenly vpn is not working anymore although it says it is connected. I am using Cyberghost as well but tried other software with the same effect (connects normally but no data goes through the vpn connection)
Haven't found a solution up till now, it is very annoying.
Where did you buy your note 9?

Mine is Australian version from Optus. No solution so far. I contacted samsung and they told me to do factory reset.. haven't tried that yet. So annoying!

Hmm ok yes i saw that too as a probable solution when people with older Samsung devices had a problem like this but factory reset i only want to do as a last resort because it's going to be a haggle to set everything right again. If i do it and it works i will reply again.
My one was bought in Thailand by the way and model number is SM-N960F/DS

Same model as yours except not DS. It seems to be a software issue. Don't know what has triggered this. It was working just fine.

It must have been triggered by the latest software update because my nephew in the Netherlands has the same issue when he tried to use the vpn just now. It worked after rebooting the phone and then his connection dropped after 10 minutes and now his vpn connection isn't working anymore.
So three Note 9 phones all bought in a different country and region have the same issue, weird that this problem hasn't come up on forums more unless the cyberghost app broke our vpn capabilities..

Oh ok that is interesting. I tried other free vpns also with same result. But I was using cyberghost before this problem...
I really don't want to do factory reset.

Same issue in Canada
I am in Canada and I'm having the same issue. What I have found, is it if I download a DNS changer, and I change the DNS, once in awhile it starts working again. But this is completely unreliable.
This seems to have been an issue for a while and for a business marketed phone, it's quite perplexing that Samsung/Google have not dealt with this issue yet.

I got a temporary solution from cyberghost. It's requires setting up L2TP vpn connection. It's not as fast but it does the trick for now. I noticed from my searches this has been an issue since Samsung S8...hopeless!

Is this a Samsung problem or an Android problem? Samsung is telling me to send my Note 9 in for repair bit I am not convinced there is anything they can do. I have tried a factory reset but it was of no help.

I guess deleting all VPN profiles from device but very one will do a thing

Did the latest samsung update but still doesn't work. Any solutions?

The only solution that worked for me is to set up vpn manually.
Add a new device at Cyberghost account management and manually enter the pre-shared key, username and password given and choose ipsec protocol and on your device choose L2TP/IPSEC PSK.
Then you have to connect to the VPN there instead of the Cyberghost App and you will have full vpn functionality although slower than the app which is using OpenVPN or Ikev2 protocol but it's better then nothing.

I use OpenVPN for Android and under Advanced you need to set 'Use VPN for All apps except' and set route all traffic over VPN.
This did change somewhere in Oreo, it didn't used to be like this.

betternet vpn works a treat. no issues with transparency 48hrs after reboot.

PIA works without issues.

Norton Mobile Security effectively disables Android encryption?

OK, this is not strictly a OP3T problem but that's where it happened to me. I run Norton Mobile Security on my phone, which is encrypted. Just recently enabled Web Protection to see if that would help speed up the incredibly long time Norton takes to analyze links before it allows pages to load. When I set it up and enabled Norton Security Services in the Accessibility menu, there was a fine-print screen that said Norton would be taking over some of the lock screen functions. No big deal.
When I rebooted the phone, it went straight to Android, without asking for the encryption password. I booted into recovery, same thing. I tried disabling Norton Web Protection, still no password. Uninstalled Norton, still no password. The Security menu shows the phone is still encrypted, which I figured because the installation didn't take long enough to decrypt the phone, and because it doesn't work that way anyway.
I tried this first on an LG G2 running Lineage 16 , but didn't notice the lack of the password prompt until it was too late, and I had done the same thing to my daily driver OP3T.
After about two hours on a chat with Norton support, they escalated me up to senior support, and said I'd get a call back in a couple of days.
So, I turn to this group. There's only one way I can explain this behavior: it appears Norton Mobile Security might be modifying the bootloader to preload the encryption password and bypass the prompt. This effectively disables decryption, since anyone can now boot my phone into recovery and ADB pull whatever they want.
The phone is fully functional, but also wide open. Short of copying everything off the phone, resetting and starting from scratch, does anyone have a suggestion? I do have TWRP backups that include the bootloader, but I don't want to overwrite the bootloader if that risks breaking the encryption entirely and locking me out of my phone.
In the meantime, be careful with Norton Mobile Security!

If memory serves me right (ha!), disabling the boot password is supposed to happen when you enable any accessibility settings...

That makes sense. The warning looked like standard Android boilerplate. Is there a way to re-enable the password prompt?

mobilityguy said:
That makes sense. The warning looked like standard Android boilerplate. Is there a way to re-enable the password prompt?
Click to expand...
Click to collapse
Yes, disable whatever accessibility setting you enabled. It's got nothing specifically to do with Norton....

Didgeridoohan said:
Yes, disable whatever accessibility setting you enabled. It's got nothing specifically to do with Norton....
Click to expand...
Click to collapse
I disabled everything I could find related to accessibility - the Norton services and the Android accessibility shortcut. What am I missing?

Also, the problem affects the recovery partition boot, which has also stopped asking for the encryption password but decrypts the phone must fine. Doesn't seem like changes to the Android options would change that.

You might have to reenable the boot password in the security settings as well.

Didgeridoohan said:
You might have to reenable the boot password in the security settings as well.
Click to expand...
Click to collapse
Yes! That did it. Opening the PIN option on the security screen brought up a prompt asking if I wanted to have the PIN prompt on boot. It now asks for passwords on both system and recovery. Thank you for the last piece of the puzzle.