Related
So I've rooted my B&N Nook HD+ using the instructions in this thread: [CWM/ROOT/UNKNOWN SOURCES] HD/HDplus Stock Root/other Mods - via CWM flashable zips
I've flashed the "Unknown Sources" and "Universal Root" zips, but I'm still a bit at a loss as how to restore the build-in Android PPTP VPN functionality that B&N seems to have removed from the Settings in the stock ROM.
I see that singlang appears to have done so based on the screenshots in this post, but it's still not clear to me exactly what he did to get that outcome. Did he flash something that restored those settings? Or was one of the apps/services in the lengthy list of disabled/frozen items what did it?
I've tried searching the forums, but that was the only post I could find referencing VPN for the Nook HD+ that wasn't about trying to get some third-party VPN app and/or other protocols (like IPSEC or OpenVPN) to work.
Thank you for your time.
Well, after some more digging and searching, I was able to get to the built-in VPN settings by using an app called "Settings Extended" (com.hb.settings) which gave me a button I could use to jump directly to the VPN settings. I'm documenting this here for the next poor soul who runs across this same problem. (Unfortunately, the forum software apparently won't actually let me link to the app, since I'm too new.)
is this the one? https://play.google.com/store/apps/details?id=com.hb.settings&hl=en
Yup! That'd be it, thanks! ^_^
Next poor soul
Kanmuri said:
I'm documenting this here for the next poor soul who runs across this same problem.
Click to expand...
Click to collapse
Just wanted to mention that I am 'the next poor soul' who found this post helpful. Thanks.
TL;DR
My ChromeCast was happily using Unblock US for Netflix for months. It stopped working on Friday. Is it a general problem, or is it just with my setup?
The long version:
I got my ChromeCast before Christmas, and I've been happily using it with multiple Netflix regions using Unblock US. On Friday I started getting the "We're having trouble playing this title" error on some titles, and it looks like my ChromeCast can no longer access non-UK titles.
It worries me that this coincides (sortof) with the official availability of ChromeCast in the UK, and I'm wondering if they've released a new build or service which prevents the use of services like Unblock US.
My ChromeCast is using build 16278 (with a worrying 'Country code GB' that I never noticed before). I'm intercepting access to Google's DNS on my router using the following iptables commands:
iptables -t nat -A PREROUTING -d 8.8.8.8 -j DNAT --to-destination 208.122.23.22
iptables -t nat -A PREROUTING -d 8.8.4.4 -j DNAT --to-destination 208.122.23.23
And as I said, these have been working fine for months. I'm also fairly confident that they're still OK, because I've set my tablet to use 8.8.8.8 as the DNS and it can access Netflix US content just fine.
So, my questions:
1. Is there anyone else in the UK using Unblock US to access Netflix using official ChromeCast build 16278? Is it still working for you? (If you want a particular title to try, Supernatural season 6 episode 13 is the one that I first noticed the problem with, although many titles refuse to play.)
2. If it's not working for you either, do you know why?
3. If it is working for you, what should I try next? (I've already done a factory reset, and that didn't make a difference.)
I've been happy with Unblock US but I'm equally happy to move to a different provider if there's a better one.
(I hope this is the right forum - it's where ChromeCast region settings and use of iptables have been discussed in the past. I'm a bit worried that the forum says I'm breaking the rules by asking a question, so if there's a better place for this post please don't be offended by my ignorance and please do let me know!)
Many thanks.
Uh oh. You say you have build 16278? That's new. My U.S. Netflix access still works, but I'm still on build 16041.
Maybe there's no cause for concern yet. The new Country Code was there in build 16041, and in any case I would think it's the Netflix app that would have to change to cause a problem rather than the Chromecast build. But obviously there should be some re-testing with build 16278 as it rolls out. Netflix could have already changed their app, but made it dependent on build 16278 or higher since everyone is going to get that sooner or later.
Regardless of the current situation, long term this Country Code is clearly going to be a problem. It can probably be solved by the DNS proxy services eventually, but until then I wouldn't be buying a Chromecast to use from outside the U.S..
DJames1 said:
Uh oh. You say you have build 16278? That's new. My U.S. Netflix access still works, but I'm still on build 16041.
Maybe there's no cause for concern yet. The new Country Code was there in build 16041, and in any case I would think it's the Netflix app that would have to change to cause a problem rather than the Chromecast build. But obviously there should be some re-testing with build 16278 as it rolls out. Netflix could have already changed their app, but made it dependent on build 16278 or higher since everyone is going to get that sooner or later.
Regardless of the current situation, long term this Country Code is clearly going to be a problem. It can probably be solved by the DNS proxy services eventually, but until then I wouldn't be buying a Chromecast to use from outside the U.S..
Click to expand...
Click to collapse
I expect we had better get used to this breakage with things like Netflix due to the fact that Google does a tiered rollout of updates and the Apps must also be updated to work with those new updates from time to time.
Netflix I think may be particularly susceptible because I suspect the Netflix Player app may actually be embedded in the device. It's the only app that does not have a LINK in the App list CCast uses to retrieve players.
Perhaps someone from Team Eureka can comment and confirm if that is true or not.
But what seems to be a pattern is Google releases an update, Something breaks and then you see a flood of CCast compat app updates a week or so later. Hopefully once the CCast OS is more mature this breakage will happen less frequently.
Just wanted to point out, sometimes if you change settings on your router or the connection is disrupted randomly, the iptables may get reset and stop intercepting Chromecast DNS requests. Rebooting the router to start the script again helps.
Sent from my Nexus 5 using Tapatalk
Asphyx said:
Netflix I think may be particularly susceptible because I suspect the Netflix Player app may actually be embedded in the device. It's the only app that does not have a LINK in the App list CCast uses to retrieve players.
Perhaps someone from Team Eureka can comment and confirm if that is true or not.
Click to expand...
Click to collapse
One of them said that Netflix was a separate binary and the only exception to running in a Chrome sandbox, so seems that is the case. It could still be cleverly coded so it wouldn't require a full update unless there was a low level or architecture change.
Asphyx said:
But what seems to be a pattern is Google releases an update, Something breaks and then you see a flood of CCast compat app updates a week or so later. Hopefully once the CCast OS is more mature this breakage will happen less frequently.
Click to expand...
Click to collapse
Yup... even with the forced updates there's still a period of time when there are units on both old and new versions, DNS caches haven't been updated, etc.
RandomUser6 said:
TL;DR
1. Is there anyone else in the UK using Unblock US to access Netflix using official ChromeCast build 16278? Is it still working for you? (If you want a particular title to try, Supernatural season 6 episode 13 is the one that I first noticed the problem with, although many titles refuse to play.)
Click to expand...
Click to collapse
Yes - though my CC still says country code US.Tried the Supernatural episode as well and that worked too.
RandomUser6 said:
3. If it is working for you, what should I try next? (I've already done a factory reset, and that didn't make a difference.)
Click to expand...
Click to collapse
I'm sure you probably already done this but have you checked your current external IP Address is active on the unblock-us website?
Some updates
Hi all,
Many thanks for all your responses. Some updates:
I checked the external IP address was active on Unblock US, and it was.
I restarted the router, the ChromeCast and the tablet. It made no difference.
I did another factory reset on the ChromeCast. It made no difference.
I managed to change the Country Code to US. It made no difference.
So I still have the problem and I’m not sure what the differences between my setup and Pully’s are.
The Country Code change is worth a bit more explanation. You all may already know this, or know how this mechanism works, but I didn’t.
* After a factory reset, I couldn’t see the ChromeCast on my tablet to set it up. I could see it with my phone. (My tablet is set to use Google’s DNS - intercepted and redirected to Unblock US’s DNS - rather than my ISP’s, location services are off, and ChromeCast has access to location services turned off in App Ops. My phone just uses regular DNS and has location services turned on.)
* I set the ChromeCast up using my phone, and it set the location (automatically) to GB. I’m not certain of this but I’ve no recollection of choosing the location at this point.
* I couldn’t get things to work and posted here. (Just so you know the timeline.)
* I did a factory reset again, and tried to set ChromeCast up using the tablet again. It still couldn’t see the reset ChromeCast. Then I changed App Ops on the tablet to allow access to location services, and it could suddenly see the ChromeCast to set it up. Location services were still turned off on the tablet, but it seems turning it off in App Ops interfered with it seeing the reset ChromeCast.
* When I tried to set it up with the tablet - now that it could see it - as part of the setup process it gave me a drop down to choose the location. I chose US. (I’ve also set it to EST/New York time and language to English (United States).
So the upshot is: I believe you can set the Country Code in build 16278 if you set it up using a device that has location services turned off, but not blocked by App Ops.
Unfortunately I’m still no further on with my Netflix problem and I’m running out of things to try.
How long does the US Country Code stick? Does it reset to GB when you power-cycle the Chromecast?
Maybe it's time to broaden your experiments to identify where the problem lies.
Instead of relying on the iptables commands you could try the static-route-to-nowhere method to block Google DNS and put the DNS addresses in your router fields for the moment. See if that makes a difference.
For an alternative DNS you could sign up for a 1-week trial with one of the others like Unotelly, or else try the free DNS services currently offered by SmartDNSProxy or Tunnelto.us. I have confirmed that they work with Netflix on the Chromecast.
If neither of those things work, at least you have eliminated some possibilities.
Right now tunnelto.us is working for me, whereas unlocater broke some time ago. SmartDNSProxy also not working for me.
Sent from my Nexus 5 using Tapatalk
It works now!
Hi folks,
I have it working now (thanks!) and have a bit more information. Some of this is just my supposition of what’s going on.
First of all, Country Code sticks between power-cycles without any problems. Time zone and language don’t seem to have any impact either. Also, I honestly have no idea whether Country Code has any effect at the minute. It might still be a red herring, or a problem for the future.
The fix was related to an idea DJames1 had. I changed my iptables to use tunnelto.us and it didn’t work either. So I tried setting the router to use Unblock US as the main DNS as well as in iptables, and it worked.
As I said before, this worked fine for months up until Friday. I don’t know if it’s the new build or something else, but I believe that something is now verifying(?) DNS using the DHCP-supplied DNS as well as Google’s hard-coded DNS.
I don’t want all machines on my home network using Unblock US’s DNS, so I updated my router config to supply Unblock US DNS entries via DHCP just to the ChromeCast. This works fine. If you want to do the same, and you’re using DD-WRT, just add this to your Additional DNSMasq Options:
dhcp-option=altdns,6,208.122.23.23,208.122.23.22
dhcp-host=#ChromeCast MAC Address#,net:altdns
Obviously you need to change #ChromeCast MAC Address# to the MAC address of your own ChromeCast. And if you want to use other DNS entries instead of Unblock US, just change the two IP addresses in the first line.
I’m sure there are other ways of achieving the same ends, but this worked for me. And the easiest option is just to use Unblock US as the DNS for your router/DHCP as well as the iptables entries.
I hope this helps anyone else who has the same problem. Many thanks for your help and advice.
RandomUser6 said:
I hope this helps anyone else who has the same problem. Many thanks for your help and advice.
Click to expand...
Click to collapse
Is there any chance that the CC is now using the DHCP given DNS addresses and is NOT hardcoding to 8.8.8.8 any more?
generationgav said:
Is there any chance that the CC is now using the DHCP given DNS addresses and is NOT hardcoding to 8.8.8.8 any more?
Click to expand...
Click to collapse
I can't say but it would make some sense that the DNS used will change depending on the Country Code of the device.
So a CCast in the UK might use a hardcoded DNS for GoogleUK server as opposed to a US server....
You're right!
generationgav said:
Is there any chance that the CC is now using the DHCP given DNS addresses and is NOT hardcoding to 8.8.8.8 any more?
Click to expand...
Click to collapse
Well now that's an incredibly good question! I'm embarrassed that that didn't occur to me and I didn't check it.
So, I deleted my iptables setup, set my tablet to use Unblock US DNS's directly (instead of using 8.8.8.8 and having that translated), and it still works.
It seems you're right. My router is providing Unblock US DNS to the ChromeCast via DHCP, and (I think) that's it. That's the only non-standard bit.
So, yes, it looks to me like it's now just taking the DHCP DNS and using that instead of Google's hardcoded DNS.
Thanks for figuring this out! (I'm still a bit embarrassed I didn't notice it.)
RandomUser6 said:
Well now that's an incredibly good question! I'm embarrassed that that didn't occur to me and I didn't check it.
So, I deleted my iptables setup, set my tablet to use Unblock US DNS's directly (instead of using 8.8.8.8 and having that translated), and it still works.
It seems you're right. My router is providing Unblock US DNS to the ChromeCast via DHCP, and (I think) that's it. That's the only non-standard bit.
So, yes, it looks to me like it's now just taking the DHCP DNS and using that instead of Google's hardcoded DNS.
Thanks for figuring this out! (I'm still a bit embarrassed I didn't notice it.)
Click to expand...
Click to collapse
Interesting. My Chromecast in Canada definitely is still using Google's hard coded DNS, but the firmware version still isn't the newer one you've reported.
Sent from my Nexus 5 using Tapatalk
RandomUser6 said:
So, yes, it looks to me like it's now just taking the DHCP DNS and using that instead of Google's hardcoded DNS.
Click to expand...
Click to collapse
That’s not the case with my chromecast (spanish, not imported, with up-to-date firmware, 16041 IIRC) :
Code:
[email protected]:~# tcpdump -nli br-lan host 10.12.30.1 and port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 65535 bytes
18:01:05.016228 IP 10.12.30.1.37745 > 8.8.8.8.53: 35107+ A? lh3.googleusercontent.com. (43)
18:01:05.061083 IP 8.8.8.8.53 > 10.12.30.1.37745: 35107 4/0/0 CNAME googlehosted.l.googleusercontent.com., A 173.194.34.235, A 173.194.34.236, A 173.194.34.234 (120)
18:02:12.584606 IP 10.12.30.1.42801 > 8.8.8.8.53: 49188+ A? clients3.google.com. (37)
18:02:12.626840 IP 8.8.8.8.53 > 10.12.30.1.42801: 49188 12/0/0 CNAME clients.l.google.com., A 173.194.41.9, A 173.194.41.0, A 173.194.41.5, A 173.194.41.1, A 173.194.41.4, A 173.194.41.6, A 173.194.41.7, A 173.194.41.2, A 173.194.41.14, A 173.194.41.8, A 173.194.41.3 (237)
18:03:06.852570 IP 10.12.30.1.54056 > 8.8.8.8.53: 18326+ A? lh4.googleusercontent.com. (43)
18:03:06.898487 IP 8.8.8.8.53 > 10.12.30.1.54056: 18326 4/0/0 CNAME googlehosted.l.googleusercontent.com., A 173.194.41.10, A 173.194.41.11, A 173.194.41.12 (120)
18:05:09.640580 IP 10.12.30.1.53769 > 8.8.8.8.53: 61549+ A? clients3.google.com. (37)
18:05:09.687719 IP 8.8.8.8.53 > 10.12.30.1.53769: 61549 12/0/0 CNAME clients.l.google.com., A 173.194.41.224, A 173.194.41.233, A 173.194.41.230, A 173.194.41.229, A 173.194.41.228, A 173.194.41.227, A 173.194.41.238, A 173.194.41.231, A 173.194.41.232, A 173.194.41.225, A 173.194.41.226 (237)
18:05:09.913235 IP 10.12.30.1.43963 > 8.8.8.8.53: 14131+ A? lh5.googleusercontent.com. (43)
18:05:09.954725 IP 8.8.8.8.53 > 10.12.30.1.43963: 14131 4/0/0 CNAME googlehosted.l.googleusercontent.com., A 173.194.41.10, A 173.194.41.12, A 173.194.41.11 (120)
My router’s dhcp server tells the clients on my network (including my chromecast) that they should use 10.12.0.1 as their dns server.
As you can see in tcpdump output above, the chromecast (10.12.30.1) is ignoring that and using 8.8.8.8.
New build?
kpiris said:
That’s not the case with my chromecast (spanish, not imported, with up-to-date firmware, 16041 IIRC) :
Click to expand...
Click to collapse
Interesting. My problems started last Friday, and mine is reporting (stock) build 16278.
Make sure you reboot router and Chromecast at the start of each test for clean results as DNS queries can be cached.
It seems that firmware 16278 has only been reported in the UK. Anyone seeing that outside of the UK?
Restart, restart, restart...
bhiga said:
Make sure you reboot router and Chromecast at the start of each test for clean results as DNS queries can be cached.
Click to expand...
Click to collapse
Yeah, today was a bit of a restart frenzy for me. Both the router and the ChromeCast have been powered off and back on again since the config changes and they continue to work.
cmstlist said:
It seems that firmware 16278 has only been reported in the UK. Anyone seeing that outside of the UK?
Click to expand...
Click to collapse
Yes here in Denmark, my cc has 16278
Hi,
I was thinking about something.
1. know were chromecast gets the update file (url checking for updates)
2. redirect your modem so it goes to another server to get an updatefile
3. updatefile is a eureka file
4. let chromecast think its original and updates the CC with this file
Maybe you can just fool the CC to update from another url with a modified image.
This would be the easiest way to hack it.
Let me know if its possible
I think it won't be possible, because of firmware keys, and security. It will check if the firmware has a digital signature. But I'm not 100% sure about that.
At the least you'd need to match the Google signature before it would install... which is much harder than it sounds.
1024 bit key, so you've got to guess a password that's 128^256 or a hella bunch of potential passwords on the apk signature.
That also assumes that only the update file is signature checked - there might be some negotiation between the Chromecast and the mothership which involves other layers.
Basically with current computing capabilities and only a signature check you're probably looking at a minimum of a few years to crack the current signature unless I did the maths wrong.
mildlydisturbed said:
At the least you'd need to match the Google signature before it would install... which is much harder than it sounds.
1024 bit key, so you've got to guess a password that's 128^256 or a hella bunch of potential passwords on the apk signature.
That also assumes that only the update file is signature checked - there might be some negotiation between the Chromecast and the mothership which involves other layers.
Basically with current computing capabilities and only a signature check you're probably looking at a minimum of a few years to crack the current signature unless I did the maths wrong.
Click to expand...
Click to collapse
It's even worse than that!
It will only take updates over HTTPS which means you need to have a server running that has Google Security certificate or nothing happens!
..
Asphyx said:
It's even worse than that!
It will only take updates over HTTPS which means you need to have a server running that has Google Security certificate or nothing happens!
Click to expand...
Click to collapse
Ok, so to update with other fw is not possible.
Did somebody even checked this possebility?
phantmbox said:
Ok, so to update with other fw is not possible.
Did somebody even checked this possebility?
Click to expand...
Click to collapse
Yep!
The last exploit took advantage of a vulnerability in the USB startup that would allow you to create multiple USB Hubs and overflow the unit to put it back into a Factory Flash mode. Once there you could load up your own rom. This is why the Teensy was required to send commands to the CCast and break it's boot cycle.
Google Patched that rather quickly!
And once the device boots there are several more layers of protection including using the aforementioned HTTPS to ensure all updates are coming from google and only google.
If you folks really want root the best way to go is to buy a NIB unit and make sure you disconnect Internet access until you have successfully rooted and flashed Eureka.
Considering the low price $35 you can recoup some of that money by selling the one that updated to a friend or relative. Even Ebay I suppose but you probably won't get full price there.
And I would do it sooner rather than Later because at some point Google will start shipping Units with the unrootable ROM in it out of the box.
Then you will have to wait until (and hope) another Exploit is found.
I can't seem to find any information to advise a description of changes or fixes for this update.
Even Open Source learned that many people won't upgrade unless they have some idea why.
Anyone find any info on it ?
uaflyer said:
I can't seem to find any information to advise a description of changes or fixes for this update.
Even Open Source learned that many people won't upgrade unless they have some idea why.
Anyone find any info on it ?
Click to expand...
Click to collapse
That's not uncommon on sub-point updates. Likely a security patch roll-up and/or minor tweaks to functionality introduced in v5.4. Often the only clue comes from the summary provided after a successful OTA update.
Davey126 said:
That's not uncommon on sub-point updates. Likely a security patch roll-up and/or minor tweaks to functionality introduced in v5.4. Often the only clue comes from the summary provided after a successful OTA update.
Click to expand...
Click to collapse
Which Amazon generally leaves out when updating. On the tablets, it doesn't even say what they're updating. But appears the patch was to stop us from 'uninstalling' their apps. A few are reporting as such, unless they did something wrong.
DragonFire1024 said:
Which Amazon generally leaves out when updating. On the tablets, it doesn't even say what they're updating. But appears the patch was to stop us from 'uninstalling' their apps. A few are reporting as such, unless they did something wrong.
Click to expand...
Click to collapse
At some point I may load up 5.4.0.1 (or whatever the latest is) to validate this claim. Will wait for further reports as early telemetry is often misleading.
It is suspected so far that 5.4.0.1 loses the prior ability to manually disable/"uninstall" Amazon apps or be rolled back to any prior builds.
Technocian said:
It is suspected so far that 5.4.0.1 loses the prior ability to manually disable/"uninstall" Amazon apps or be rolled back to any prior builds.
Click to expand...
Click to collapse
One user reported as such. So far there hasn't been other reports.
DragonFire1024 said:
One user reported as such. So far there hasn't been other reports.
Click to expand...
Click to collapse
So I just received a 2017 HD8 yesterday (Amazon was having a fire sale on the HD 8), and it came with 5.4.0.0 but said it had a 5.4.0.1 pending.
Not knowing that 5.4.0.1 (supposedly) removed the ability to uninstall/remove certain apps, I went ahead and did it.
Now that I'm on 5.4.0.1, the System Updates page says "There are 13 system component updates ready to install". Anyone know what those are and why they weren't part of 5.4.0.1?
I did try to uninstall (using ADB) a common app to make my lock screen nicer (not sure I'm allowed to say exactly what it is?) but it seemed to still work. I do have those 13 system components that need to be updated, so I suppose those could either reverse and/or hamper further uninstall attempts. Not sure.
Has anyone done this yet? Also, is there a way to tell the Fire tablet NOT to upgrade to 5.4.0.1 (or any future updates)?? It seems that they automatically update themselves.
Update: those 13 system components seemed to install themselves. After a restart, it seems to still be working (no lock screen) and Google Play Store is working.
Update2: after some time, the lock screen comes back. SAD!! Tried re-patching again, it's gone for a bit, then after a few hours, the lockscreen returns.
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.