Database Users

Security breach found on htc devices

The Vulnerability
In recent updates to some of its devices, HTC introduces a suite of logging tools that collected information. Lots of information. LOTS. Whatever the reason was, whether for better understanding problems on users' devices, easier remote analysis, corporate evilness - it doesn't matter. If you, as a company, plant these information collectors on a device, you better be DAMN sure the information they collect is secured and only available to privileged services or the user, after opting in.
That is not the case. What Trevor found is only the tip of the iceberg - we are all still digging deeper - but currently any app on affected devices that requests a single android.permission.INTERNET (which is normal for any app that connects to the web or shows ads) can get its hands on:
the list of user accounts, including email addresses and sync status for each
last known network and GPS locations and a limited previous history of locations
phone numbers from the phone log
SMS data, including phone numbers and encoded text (not sure yet if it's possible to decode it, but very likely)
system logs (both kernel/dmesg and app/logcat), which includes everything your running apps do and is likely to include email addresses, phone numbers, and other private info
Normally, applications get access to only what is allowed by the permissions they request, so when you install a simple, innocent-looking new game from the Market that only asks for the INTERNET permission (to submit scores online, for example), you don't expect it to read your phone log or list of emails.
But that's not all. After looking at the huge amount of data (the log file was 3.5MB on my EVO 3D) that is vulnerable to apps exploiting this vulnerability all day, I found the following is also exposed (granted, some of which may be already available to any app via the Android APIs):
active notifications in the notification bar, including notification text
build number, bootloader version, radio version, kernel version
network info, including IP addresses
full memory info
CPU info
file system info and free space on each partition
running processes
current snapshot/stacktrace of not only every running process but every running thread
list of installed apps, including permissions used, user ids, versions, and more
system properties/variables
currently active broadcast listeners and history of past broadcasts received
currently active content providers
battery info and status, including charging/wake lock history
and more
Let me put it another way. By using only the INTERNET permission, any app can also gain at least the following:
ACCESS_COARSE_LOCATION Allows an application to access coarse (e.g., Cell-ID, WiFi) location
ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location
ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location provider commands
ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks
BATTERY_STATS Allows an application to collect battery statistics
DUMP Allows an application to retrieve state dump information from system services.
GET_ACCOUNTS Allows access to the list of accounts in the Accounts Service
GET_PACKAGE_SIZE Allows an application to find out the space used by any package.
GET_TASKS Allows an application to get information about the currently or recently running tasks: a thumbnail representation of the tasks, what activities are running in it, etc.
READ_LOGS Allows an application to read the low-level system log files.
READ_SYNC_SETTINGS Allows applications to read the sync settings
READ_SYNC_STATS Allows applications to read the sync stats
Theoretically, it may be possible to clone a device using only a small subset of the information leaked here.
I'd like to reiterate that the only reason the data is leaking left and right is because HTC set their snooping environment up this way. It's like leaving your keys under the mat and expecting nobody who finds them to unlock the door. For a more technical explanation, see the section below.
Additionally, and the implications of this could end up being insignificant, yet still very suspicious, HTC also decided to add an app called androidvncserver.apk to their Android OS installations. If you're not familiar with the definition of VNC, it is basically a remote access server. On the EVO 3D, it was present from the start and updated in the latest OTA. The app doesn't get started by default, but who knows what and who can trigger it and potentially get access to your phone remotely? I'm sure we'll know soon enough - HTC, care to tell us what it's doing here?
Technical Details
In addition to Carrier IQ (CIQ) that was planted by HTC/Sprint and prompted all kinds of questions a while ago, HTC also included another app called HtcLoggers.apk. This app is capable of collecting all kinds of data, as I mentioned above, and then... provide it to anyone who asks for it by opening a local port. Yup, not just HTC, but anyone who connects to it, which happens to be any app with the INTERNET permission. Ironically, because a given app has the INTERNET permission, it can also send all the data off to a remote server, killing 2 birds with one stone permission.
In fact, HtcLogger has a whole interface which accepts a variety of commands (such as the handy :help: that shows all available commands). Oh yeah - and no login/password are required to access said interface.
Furthermore, it's worth noting that HtcLogger tries to use root to dump even more data, such as WiMax state, and may attempt to run something called htcserviced - at least this code is present in the source:
/system/xbin/su 0 /data/data/com.htc.loggers/bin/htcserviced
HtcLoggers is only one of the services that is collecting data, and we haven't even gotten to the bottom of what else it can do, let alone what the other services are capable of doing. But hey - I think you'll agree that this is already more than enough.
Patching The Vulnerability
... is not possible without either root or an update from HTC. If you do root, we recommend immediate removal of Htcloggers (you can find it at /system/app/HtcLoggers.apk).
Stay safe and don't download suspicious apps. Of course, even quality-looking apps can silently capture and send off this data, but the chance of that is lower.
Affected Phones
Note: Only stock Sense firmware is affected - if you're running an AOSP-based ROM like CyanogenMod, you are safe.
EVO 4G
EVO 3D
Thunderbolt
EVO Shift 4G? (thanks, pm)
MyTouch 4G Slide? (thanks, Michael)
the upcoming Vigor? (thanks, bjn714)
some Sensations? (thanks, Nick)
View 4G? (thanks, Pat)
the upcoming Kingdom? (thanks, Pat)
most likely others - we haven't verified them yet, but you can help us by downloading the proof of concept above and running the APK
HTC's Response
After finding the vulnerability, Trevor contacted HTC on September 24th and received no real response for five business days, after which he released this information to the public (as per RF full disclosure Policy). In my experience, lighting fire under someone's ass in public makes things move a whole lot faster, which is why responsible disclosure is a norm in the security industry. (This is where we come in.)
As far as we know, HTC is now looking into the issue, but no statement has been issued yet.
HTC, you got yourself into this mess, and it's now up to you to climb out of the hole as fast as possible, in your own interest.
The ball is in your court.
Credit
ANDROID POLICE
Huge thank you to Trevor Eckhart who found the vulnerability and Justin Case for working with us today digging deeper.

Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?

zzm5 said:
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
Click to expand...
Click to collapse
Is your device rooted?

I used root explorer and removed the HtcLoggers.apk and other than the forced close loop that removing it caused (requiring me to remove the battery), after rebooting all seems to be working fine.
EDIT: Actually I didn't just delete HtcLoggers.apk but moved it to a safe location on the SD Card in case there was a problem and it needed to be restored. I highly suggest you do this instead of just deleting it, or better yet, a nandroid backup.

there are a few good ROMS out there that have the ICQ loggers removed already.

Do we really need three threads on the front page about the same thing?

[REQEST] Working google wallet

I'm looking for working moded google wallet with tap to pay for LG G2 ATT... Thanks

You'll only get it to work if you change your build.prop file.
Sent from my LG-D800 using Tapatalk 2

Google Wallet
I mean could we possibly change our build prop to the lg nexus, or sprint variant of the phone and have it tricked to think its not carrier specific. I did this to my vzw s3 by changing it to the sprints s3 build prop rebooted and VALA! there was google wallet and with nfc i tested out in a few stores and it worked!

secure element
I've been under the impression that google wallet wont look on the sim for the secure element and the g2 doesn't have one built in like the s3. I've done the build.prop and xposed methods without luck so far. keep climbing...

changing the build.prop will not work on this phone.
The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
This is not due to our phone being inable to work technically, but Google simply hasnt added support for NFC Secure Elements contained in SIM cards.
It's completely possible to that even if/when google adds support for that, that VZW will have some sort of lock on the SIM that will still break it for us.
Add this to the fact that even ISIS doesnt work on this phone (or at least all previous root check bypasses I've tried dont work) and the fact that ISIS sucks... And you have a very non capable phone as far as tap-to-pay is concerned. Not sure if anything can be done by modders as far as the Secure Element in SIM issue is concerned, Here's hoping, but I have a feeling we're gonna have to hold out until Google at least adds the base support, and then mod past anything else verizon throws at us from there.

http://forum.xda-developers.com/showthread.php?t=2457569
Will this work on the G2?

sansart said:
http://forum.xda-developers.com/showthread.php?t=2457569
Will this work on the G2?
Click to expand...
Click to collapse
No.... reread Waco's post above yours.....

I installed this on my t-mo g2, don't know if this is what your looking for.

Ready2Mosh said:
I installed this on my t-mo g2, don't know if this is what your looking for.
Click to expand...
Click to collapse
Yes it installs, but what people want to work is tap to pay, and it doesn't ....

Sprint G2 coming... cross your fingers
Sprint has been the savior many times over for each phone that didn't support Google wallet on the other carriers. They are releasing the G2 in the beginning of November.
We'll have to wait and hope that we can pull the correct files from the Sprint model and enable the secure element that way.
I'm not the person to do it but I bet someone reading this is....

http://forum.xda-developers.com/showthread.php?t=2486738
This thread has a system dump of the Sprint G2 for anyone who wants to take a look through it for the files needed.

WACOMalt said:
changing the build.prop will not work on this phone.
The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
This is not due to our phone being inable to work technically, but Google simply hasnt added support for NFC Secure Elements contained in SIM cards.
It's completely possible to that even if/when google adds support for that, that VZW will have some sort of lock on the SIM that will still break it for us.
Add this to the fact that even ISIS doesnt work on this phone (or at least all previous root check bypasses I've tried dont work) and the fact that ISIS sucks... And you have a very non capable phone as far as tap-to-pay is concerned. Not sure if anything can be done by modders as far as the Secure Element in SIM issue is concerned, Here's hoping, but I have a feeling we're gonna have to hold out until Google at least adds the base support, and then mod past anything else verizon throws at us from there.
Click to expand...
Click to collapse
Fyi, the xposed module in thread http://forum.xda-developers.com/showthread.php?t=2425346 allowed me to get past the root check. Isis still sucks and wouldn't accept my credit cards, but the root check seems to be defeated.
Sent from my VS980 4G using Tapatalk

WACOMalt said:
...The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
Click to expand...
Click to collapse
We now know that Google Wallet will install and function on most current Android phones. The tap and pay function now relies on a simulated secure element to allow NFC transactions. As of today, the only phone without the hardware secure element that is said to have successfully implemented the tap and pay feature, is the Sprint G2. There has been a Sprint system dump out in XDA for a few weeks now, but I have not seen any further development on tap and pay functionality on any of the other G2 variants.
I've searched, but was unable to find any successful tap and pay transactions for the Nexus 5 yet in the US. Is it too early? I would've thought someone would have tried it by now...

This isn't Google's problem
WACOMalt said:
changing the build.prop will not work on this phone.
The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
This is not due to our phone being inable to work technically, but Google simply hasnt added support for NFC Secure Elements contained in SIM cards.
It's completely possible to that even if/when google adds support for that, that VZW will have some sort of lock on the SIM that will still break it for us.
Add this to the fact that even ISIS doesnt work on this phone (or at least all previous root check bypasses I've tried dont work) and the fact that ISIS sucks... And you have a very non capable phone as far as tap-to-pay is concerned. Not sure if anything can be done by modders as far as the Secure Element in SIM issue is concerned, Here's hoping, but I have a feeling we're gonna have to hold out until Google at least adds the base support, and then mod past anything else verizon throws at us from there.
Click to expand...
Click to collapse
This has nothing to do with Google's implementation or support. They are being prevented by T-Mo/ATT/VZ from accessing the Secure Element.
The Secure Element is not on the battery. Samsung put their NFC antenna in the battery (maybe that's what you're thinking), but the Secure Element is in the phones circuitry or on the SIM or a SD card. Google does support secure elements in SIM's. T-Mo/ATT/VZ wont allow any applications other than theirs to access the secure element in the SIM.

I use Google wallet everyday on my VZW G2. It works great if you are running CM. Not really sure if it will run on stock as I have not tried.
Sent from my LG-VS980 using xda app-developers app

[Q] is there a patch for this bug 13678484 (fake id)

can anyone make a patch for all variants of hd2 roms from gb up i used the bluebox app to check if my phone was vunerable for this bug 13678484 (fake id) and my daily driver barebone cm7 v2b was, and id say all roms developed for hd2 are vunerable have searched the net for how to patch this vunerability but cant find the info abywhere this is something i think all xda devs for this device will have to sort out as we cannot get help from carriers on this as this is what advice is given "contact your carrier or phone vendor for patch. if anyone has advice on how to sort this out would be very thankful i think xda should run a piece about this vunerability and what steps are being taken by all devs on xda to patch this vunerabilitu for older handsets likemy hd2.

Bluebox Security revealed a significant security flaw that affects all Android devices since version 2.1. Our hyperbolic title mocks the fact that he had little to ignite the Internet powders. If the fault is real, it should take a step back and put the case in context instead of screaming panic for nothing.
A serious flaw that affects a large number of terminals
Very schematically, the fault Fake ID allows malware to authenticate using the signature of a known application to hide its true origin. The firm provides an example of a virus masquerading as an Adobe Systems and Google software which would be able to become a Trojan horse or steal data used by Google Wallet acquiring the necessary permissions without using the user.
The flaw is serious. However, Google has already been made ​​aware, he has already released a patch he sent to his partners, he corrected the flaw in Android 4.4 KitKat, he scanned the Google Play and can say that no application in its store uses this vulnerability. Finally, Verify Apps, which monitors the behavior of applications on an Android device, is also fixed and can detect an application attempting to exploit Fake ID.
A patch already in place and a flaw in a very limited scope that still show that Google still has work to do in terms of security
In short, it is true that it is possible to be a victim of this fault, but it requires a terminal that has not been updated, download an application containing malware does not come from Google and Play Verify Apps have disabled or have an Android version of which is free. Suffice to say that the cases in question are very limited.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.

This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.[/QUOTE]
while the info you have given is fine and i thank you for it, but there are other app stores people use beside google play store and reading up on this bug it is still possible their phones could become compromised downloading apps from them?

A Big Big Thank You
Just an update: opssemnik backported the fake id xposed module and it works perfectly with gb roms a big big thank you to him. he also supplied a link in the comments on http://www.xda-developers.com/android/fight-fake-id-vulnerability-xposed/ So once again a big thank you to opssemnik

Rooting and Fixing Samsung Galaxy Tab E (SM-T560NU) (and fixing -504 issue)

Disclaimer: I know this should go in the correct subforum for my device, but I'm having trouble navigating this site, altogether. I only see subforums for a handful of devices. So if there is a better place for this thread, I apologize
Oh, where to begin. My wonderful girlfriend got me this tablet back in october, since i said it'd be nice to have a linux based tablet so i wouldn't have apple telling me what i can and cannot do with my device (she saw that as a hint, even though it was more social commentary, but I'll take it). Anyway, I found the 16GB limitation problematic, so I decided to root it so i could use some sort of sshfs app to create a slow multi-terabyte harddrive space to steam small files (like music) from. Seeing as i had the thing for only a week and it's kind of expensive, even for a nurse, to buy for me, i chickened out and made due with a small 8GB microSD card which i just happened to have laying around.
Fast forward to a few days ago, I ordered from Amazon a 128GB microSD card (also from samsung), and decided to try to make due with that. Only to find out (and, if you're able to help me you've probably met the following issues yourselves) that the seemingly largest apps refuse to let you move them to external storage. Even better, there's some apps like Star Wars KOTOR (2.5GB) that say they let you move them, but in reality they stay on internal storage and create empty folders on the external medium. And then many apps cannot write and read to and from SD cards (like DOSbox Turbo), for reasons that completely stump me (which leads to me having to move dos games back and forth when i want to play one that saves). I then read about this wonderful feature called "Adoptable Storage," and promptly go through all sorts of things to try to enable it, only to find out that, since I have Android Version 6.0.1 from Samsung, that feature was disabled by them. After using the email support to berate them (they don't have a suggestion box), decided to try to come here and figure out how to properly root this device and figure out how to solve my space issue (I have 128GB of space that I need to use, but have no idea how to use it for what i need to use it for). By the way, a small shoutout to Samsung support, despite my very terse response, there clearly was a human being at the other end and this human was very, very civil and said that they'll pass it on as feedback (I got the impression that the employee either had the same issue or at least wanted me to know that there have been alot of complaints about this issue).
Anyway, now that that wall of text is over, this is how far i've gotten.
I know that XDA is reliable, they've had problems in the past with malware, but it was unintentional and the ship has been cleaned. I don't know about anywhere else, so the rooting instructions i find elsewhere i assume are probably correct, but i don't know where to get files for the process that i can trust, outside of XDA (and i'm having trouble finding the files i need, here).
I have a nice little article from techbeasts.com ( techbeasts.com/install-twrp-and-root-samsung-galaxy-tab-e/ ), but I don't know where their downloads came from and how many people checked them out for windows and android trojans and such.
So...
1. Is that article accurate for android 6.0.1?
2. Are those files safe (free from corruption and viruses)?
3. If they're not safe, where can I get safe files?
4. I like to develop programs, and I want to be able to develop apps for android as well. Once rooted, how does one test how their app would work on an unrooted device to ensure the app follows the "proper procedures?"
5. How do I deal with apps that are root sensitive? The point of all this is so that I can keep using my apps, so if they all break because i'm rooted that defeats the purpose.
6. Other than having to be careful with what i do (I've used Linux for years, and I occasionally like to code in assembly), that it voids my warranty, and that screwing up can make for a really bad day, is there anything else that I should know? This is, indeed, my first touch screen device outside of Nintendo products, because my V3xi is fine for me as a phone.
EDIT:
7. Forgot the most important question: How would I go about getting adoptable storage working on this device once it is rooted?
Forward: Given the nature of my question, the URL is absolutely necessary. After I've gotten my "10 useful posts" I'll fix the URL for future viewers.
EDIT2: Decided to take a chance. Ran into some issues finding the "stock firmware" which I ended up having to do. For those that have problem getting TWRP to stick, you gotta flash the stock firmware of the version you have currently installed. I tried to flash the original that it came with, which, for some reason, it didn't like at all.
Oh, and don't turn off OEM mode after everything's done. I assumed that after everything was installed it wouldn't second guess it and i could safely turn it off for added security if any app went rogue or something. Nope, must keep it on, so do regular backups. Turn off auto-updating, etc. I hear there's some sort of app that lets you "update safely." Not sure what it is, but unless you *NEED* it, don't do it.
And as a bonus note (so it shows up in the archives), some apps didn't install right (either google or the app developer's fault, but these apps weren't tied to this process [pokemon go and just about all the final fantasy games]). The kicker about this is is that you will not notice this UNTIL you uninstall the app, and reinstall it. Deleting the data before uninstalling the app will make it unstable. To find the data, i used
Code:
du / | grep "pokemon" > pokesearch.log
, since i knew that there should not have been a pokemon related directory on my droid at the time, since i needed to reinstall pokemon go because it was acting really fruity. Deleting the folders (actually, the last entry contains the rest, so it's easier just to delete the last one) allowed me to avoid the -504 issue (not to be confused with 504).
Code:
[email protected]:/data/data/com.termux/files/home # cat pokesearch.log
4 /mnt/expand/07aa2c40-4a8f-428c-afb9-7495df69eb26/user/0/com.nianticlabs.pokemongo/cache
1192 /mnt/expand/07aa2c40-4a8f-428c-afb9-7495df69eb26/user/0/com.nianticlabs.pokemongo/code_cache
12 /mnt/expand/07aa2c40-4a8f-428c-afb9-7495df69eb26/user/0/com.nianticlabs.pokemongo/shared_prefs
4 /mnt/expand/07aa2c40-4a8f-428c-afb9-7495df69eb26/user/0/com.nianticlabs.pokemongo/files
1220 /mnt/expand/07aa2c40-4a8f-428c-afb9-7495df69eb26/user/0/com.nianticlabs.pokemongo

Message me if have the same tablet on a system root
Sent from my SM-S907VL using Tapatalk

denakor said:
Message me if have the same tablet on a system root
Sent from my SM-S907VL using Tapatalk
Click to expand...
Click to collapse
We can talk here for the benefit of the community. Any problems you might have should be documented for the sake of the community. But, yes, the -504 error i mentioned above can only be solved through root, so, yes, i was successful.

Kohlrak said:
We can talk here for the benefit of the community. Any problems you might have should be documented for the sake of the community. But, yes, the -504 error i mentioned above can only be solved through root, so, yes, i was successful.
Click to expand...
Click to collapse
I have the same tablet
---------- Post added at 09:32 PM ---------- Previous post was at 09:28 PM ----------
keith thibodeau said:
I have the same tablet
Click to expand...
Click to collapse
Tablet just updated itself after I tried to root it .. MM 7.0.1 but I didnt ask it to

I disabled automatic updates (from settings and google play, 'cause it's in both places) to prevent this problem. There might be a new firmware for the tablet, but i'm sticking to this version. I'm not sure you can downgrade after you upgrade, though. You can take a shot, though, if you're not afraid of loosing data. I doubt this process will brick as long as you can get the official firm ware on backup incase something goes wrong.

Kohlrak said:
We can talk here for the benefit of the community. Any problems you might have should be documented for the sake of the community. But, yes, the -504 error i mentioned above can only be solved through root, so, yes, i was successful.
Click to expand...
Click to collapse
Now it seems impossible to root without pc

My rooted unregistered Nook Simple Touch chews battery like crazy

I got a Like New NST, reset it, unregistered it, and rooted it. I haven't replaced the kernel yet. But I have noticed that (even before I rooted it) the battery consumption is unacceptable. I've seen some old threads about this (for example https://forum.xda-developers.com/showthread.php?t=1475070) , and some suggested removing some APKs like Phone.apk and TelephonyProvider.apk, while others suggested removing or disabling some B&N-related APKs.
The thing is that some other threads seem to imply these solutions are bogus and that they don't really help. There is a lot of conflicting information spread around on this topic.
Does anybody know if there is a solution to this issue? I'm really loving the NST, it's an amazing reader in all ways except for this glaring issue.
Thanks!

Winston S. said:
I got a Like New NST, reset it, unregistered it, and rooted it. I haven't replaced the kernel yet. But I have noticed that (even before I rooted it) the battery consumption is unacceptable. I've seen some old threads about this (for example https://forum.xda-developers.com/showthread.php?t=1475070) , and some suggested removing some APKs like Phone.apk and TelephonyProvider.apk, while others suggested removing or disabling some B&N-related APKs.
The thing is that some other threads seem to imply these solutions are bogus and that they don't really help. There is a lot of conflicting information spread around on this topic.
Does anybody know if there is a solution to this issue? I'm really loving the NST, it's an amazing reader in all ways except for this glaring issue.
Thanks!
Click to expand...
Click to collapse
I sympathize and don't want to add to the conflicting information. Read what I wrote here: https://forum.xda-developers.com/showpost.php?p=78287581&postcount=2 under "Decrapify system/app". I can tell you definitively that Phone.apk has little or nothing to do with your battery drain. I did a major study on that issue a long time ago: https://forum.xda-developers.com/nook-touch/general/battery-usage-phone-apk-t3341370

nmyshkin said:
I sympathize and don't want to add to the conflicting information. Read what I wrote here: https://forum.xda-developers.com/showpost.php?p=78287581&postcount=2 under "Decrapify system/app". I can tell you definitively that Phone.apk has little or nothing to do with your battery drain. I did a major study on that issue a long time ago: https://forum.xda-developers.com/nook-touch/general/battery-usage-phone-apk-t3341370
Click to expand...
Click to collapse
Thank you for all your work, you are very methodic and logical, and I appreciate your generosity sharing all your knowledge about the NST (I have been reading up on different things here before I decided to buy one.) :good:
So, to condense all this, it looks as if neither deleting Phone.apk nor disabling B&N apps helps with battery consumption. Also, am I correct in concluding that having an unregistered Nook (or a Nook which is offline, even if registered) will invariably result in poor battery life? That's quite unfortunate, as I was planning to use my NST as a fully offline device.

Winston S. said:
So, to condense all this, it looks as if neither deleting Phone.apk nor disabling B&N apps helps with battery consumption. Also, am I correct in concluding that having an unregistered Nook (or a Nook which is offline, even if registered) will invariably result in poor battery life? That's quite unfortunate, as I was planning to use my NST as a fully offline device.
Click to expand...
Click to collapse
Almost, but fortunately not quite right. Although B&N did some questionable stuff when they cobbled together the NST/G system, I don't think they expected the devices to spend a lot of time online. If the system detects that there is no WiFi, it just slaps a post-it on its internal "refrigerator" to remind it to try a check-in later. All of that happens pretty quickly and in the grand scheme of things Android where stuff is not always killed outright even when you've finished with it, it's not a Big Deal.
So register and forget. It's the easiest path to device stability and the intended power consumption pattern.

nmyshkin said:
Almost, but fortunately not quite right. Although B&N did some questionable stuff when they cobbled together the NST/G system, I don't think they expected the devices to spend a lot of time online. If the system detects that there is no WiFi, it just slaps a post-it on its internal "refrigerator" to remind it to try a check-in later. All of that happens pretty quickly and in the grand scheme of things Android where stuff is not always killed outright even when you've finished with it, it's not a Big Deal.
So register and forget. It's the easiest path to device stability and the intended power consumption pattern.
Click to expand...
Click to collapse
Thank you again, I suppose if that's the case then I will register my NST. A couple questions: So if I register the device and never again connect to Wireless that "refrigerator post-it" won't expire?
And, most importantly, if I register with B&N will they push the 1.2.2 update on my device, or can I prevent that without any ill effect? I'd really like to stick to 1.2.1.
EDIT: I read your previous OP about the 1.2.2 OTA update, and your link for how to block it here: https://forum.xda-developers.com/showpost.php?p=34433959&postcount=3
Renate NST also suggested deleting /system/app/DeviceManager.apk, but I don't know if this would be problematic with the B&N registration issue I'm trying to fix to begin with.
Is there a preferred way to do this and still keep the device registered and battery life unscathed?
I appreciate your help!

Winston S. said:
Thank you again, I suppose if that's the case then I will register my NST. A couple questions: So if I register the device and never again connect to Wireless that "refrigerator post-it" won't expire?
And, most importantly, if I register with B&N will they push the 1.2.2 update on my device, or can I prevent that without any ill effect? I'd really like to stick to 1.2.1.
EDIT: I read your previous OP about the 1.2.2 OTA update, and your link for how to block it here: https://forum.xda-developers.com/showpost.php?p=34433959&postcount=3
Renate NST also suggested deleting /system/app/DeviceManager.apk, but I don't know if this would be problematic with the B&N registration issue I'm trying to fix to begin with.
Is there a preferred way to do this and still keep the device registered and battery life unscathed?
I appreciate your help!
Click to expand...
Click to collapse
I think since you are just starting out working with the device and don't have work to lose by updating and re-rooting, registering and then updating (you can do it manually by downloading the file yourself) is your best bet. The device keeps a "last date contacted" and "next date to try contact" in settings.db. If there is no WiFi, it will just keep changing the dates. That's all.
OTOH, if you do not update but NEVER connect to WiFi, there will probably be no issue. The method to block updates "works", as I found, but it did not prevent the occasional reboot when I was connected to WiFi, so I finally just threw in the towel and updated my devices, starting over from scratch. I'm happy with the many changes I've made since, so it worked out for me. Not sure why you want to stay with 1.2.1. It is virtually identical to 1.2.2 and I don't believe there is anything on-site here that worked with 1.2.1 which doesn't also work with 1.2.2. All B&N did was patch contacts with their servers for TLS 1.2 compliance.
Deleting/disabling DeviceManager will give your NST Alzheimers as far as your registration is concerned and it will just begin wondering why it can't remember who it is and how/when to phone home--wherever that is. One of the problems with disabling B&N apps is that there are also jar files which don't get disabled and the system still tries to fool with those. You can delete/disable those as well but the more you niggle at the system architecture the more unstable the device becomes and the more things fail to work properly (like the Reader and Library).
Like I said before, it's better AND easier to just treat the device the way it was designed as far as updating or registering. You don't have to use a credit card, you don't even have to use a real e-mail address, I suppose. Then when all that is out of the way you can just install your own launcher and set the "n" button to Home. Voila! You'll never see or hear from the B&N stuff again and your battery will last a good long time.

nmyshkin said:
I think since you are just starting out working with the device and don't have work to lose by updating and re-rooting, registering and then updating (you can do it manually by downloading the file yourself) is your best bet. The device keeps a "last date contacted" and "next date to try contact" in settings.db. If there is no WiFi, it will just keep changing the dates. That's all.
OTOH, if you do not update but NEVER connect to WiFi, there will probably be no issue. The method to block updates "works", as I found, but it did not prevent the occasional reboot when I was connected to WiFi, so I finally just threw in the towel and updated my devices, starting over from scratch. I'm happy with the many changes I've made since, so it worked out for me. Not sure why you want to stay with 1.2.1. It is virtually identical to 1.2.2 and I don't believe there is anything on-site here that worked with 1.2.1 which doesn't also work with 1.2.2. All B&N did was patch contacts with their servers for TLS 1.2 compliance.
Deleting/disabling DeviceManager will give your NST Alzheimers as far as your registration is concerned and it will just begin wondering why it can't remember who it is and how/when to phone home--wherever that is. One of the problems with disabling B&N apps is that there are also jar files which don't get disabled and the system still tries to fool with those. You can delete/disable those as well but the more you niggle at the system architecture the more unstable the device becomes and the more things fail to work properly (like the Reader and Library).
Like I said before, it's better AND easier to just treat the device the way it was designed as far as updating or registering. You don't have to use a credit card, you don't even have to use a real e-mail address, I suppose. Then when all that is out of the way you can just install your own launcher and set the "n" button to Home. Voila! You'll never see or hear from the B&N stuff again and your battery will last a good long time.
Click to expand...
Click to collapse
The main reason I want to avoid 1.2.2 is because I tend to value stability overall, and since most of the stuff here was created by the era of 1.2.1 or before, I am leery of doing something that will make things less compatible. Plus I am distrustful of B&N changes on a device this old. I also thought I had read you explaining some changes that needed to be done after a 1.2.2 update to make something work (NM, maybe? I forget.)
So my question was more along the lines of whether, when I register the device, it will be flagged immediately for update and cause some trouble if I don't, or even if the update will be downloaded in the background without me being able to do anything about it. I suppose I could always patch the sqlite file to disable OTA updates and then register. That would be the safest way to go. And you need to use ADB for this to work, right? There is no way to edit the file onboard the NST itself?
I can't wait for the battery consumption to be normal, because I am really enjoying my NST with its great ergonomy and the ability to install different readers. Mine is going to be a dedicated offline ebook reader, but a great one. And much of the reason it is so amazing is thanks to folks like you and Renate who have contributed so much. :good:

Winston S. said:
The main reason I want to avoid 1.2.2 is because I tend to value stability overall, and since most of the stuff here was created by the era of 1.2.1 or before, I am leery of doing something that will make things less compatible. Plus I am distrustful of B&N changes on a device this old. I also thought I had read you explaining some changes that needed to be done after a 1.2.2 update to make something work (NM, maybe? I forget.)
So my question was more along the lines of whether, when I register the device, it will be flagged immediately for update and cause some trouble if I don't, or even if the update will be downloaded in the background without me being able to do anything about it. I suppose I could always patch the sqlite file to disable OTA updates and then register. That would be the safest way to go. And you need to use ADB for this to work, right? There is no way to edit the file onboard the NST itself?
Click to expand...
Click to collapse
There's really no reason to be concerned about the 1.2.2 update. It's all fine. B&N would not go to the trouble on an old device like this only to somehow wreck it. It's just a TLS security update and involves connection to their servers. Since you do not intend to use the device online, the only minor issue (resigning Opera Mobile browser-- which I've already provided elsewhere) is moot for you.
As for changing the OTA flag, you can do it via ADB if you install sqlite3. This is probably best since moving settings.db back onto the device after editing can be tricky. But you could eliminate the entire tango by just updating to 1.2.2 and going on with your life

nmyshkin said:
There's really no reason to be concerned about the 1.2.2 update. It's all fine. B&N would not go to the trouble on an old device like this only to somehow wreck it. It's just a TLS security update and involves connection to their servers. Since you do not intend to use the device online, the only minor issue (resigning Opera Mobile browser-- which I've already provided elsewhere) is moot for you.
As for changing the OTA flag, you can do it via ADB if you install sqlite3. This is probably best since moving settings.db back onto the device after editing can be tricky. But you could eliminate the entire tango by just updating to 1.2.2 and going on with your life
Click to expand...
Click to collapse
Thank you for clarifying that, I think I have had an overdose of information from reading too many threads in a short span of time and somehow I got the idea NookManager had some sort of issue after the 1.2.2 update that required some tinkering. The fact that the update is limited to the TLS update means it doesn't affect me, so things would be OK. On the other hand, not installing the update also seems like wouldn't be an issue and I really wanted to get ADB going anyway to install things wirelessly, so the most logical path seems to go through the minimal effort required to change that setting anyway. It turns out I already have sqlite3 installed (I am running an Ubuntu system,) so even more reason to do this!
I'll be reading up on the way to get ADB working.
BTW, I know you have proposed probably changing NookManager to address different issues you have encountered. Let me know if I can be of any help. I have no experience building Android components and limited experience compiling, but I would be happy to learn a new skill.
Thanks! :good:

@nmyshkin I easily managed to change the OTA setting through USB ADB. (I'm keeping track of all this process so when I have everything set up I will create a thread for posterity to help anyone else with the same questions.)
Now, the problem I wasn't anticipating is that I didn't foresee the battery problems, so I used that procedure to avoid the Register prompt on startup (Bypass OOBE procedure.) But of course now I don't know how to register the Nook. Do I need to reset to Factory using NookManager, root, disable OTA, and then register? It would be nice if there is a way to avoid this?
EDIT: Searching through another thread I saw your suggestions (almost 3 years old) to use the DeviceRegistrator, so after creating a B&N account I did and it said that the registration was successful, but in Settings the Account is showing up as unavailable, so I restarted the NST, and still I am getting Account Unavailable under Settings. Does the Device Registrator not work anymore? Or have B&N stop registering NST devices?
So I checked by logging into the B&N account and as expected there are no NSTs linked to my account. The DeviceRegistrator app has a few options (Register Device, Authenticate Device, Register User, and Authenticate User.) I didn't touch the User options so I guess that is to create a new account. I just used the "Register Device" option. Do I need to Authenticate Device too, or is this just not working anymore?
I read somewhere that there is also another app called OOBE Reg or something like that that basically runs the default registration procedure, but I haven't found that app in my NST.

I actually went down a similar rabbit hole myself at one point when I was investigating selective disabling of B&N apps, etc. Yes, you need to authenticate. That may or may not have the desired effect. Right now DeviceRegistrator is your only option. It may or may not be possible to authenticate a rooted device by this method.
Having said that, maybe it's time to take a step back and ask yourself whether all this angst is worth the end result when the path of least resistance will yield an equally functional result. The answer to that depends, in part, on how much other stuff you have already done. But before you do more things don't forget that the basic device needs to be in optimum working condition (like not eating battery) first.

nmyshkin said:
I actually went down a similar rabbit hole myself at one point when I was investigating selective disabling of B&N apps, etc. Yes, you need to authenticate. That may or may not have the desired effect. Right now DeviceRegistrator is your only option. It may or may not be possible to authenticate a rooted device by this method.
Having said that, maybe it's time to take a step back and ask yourself whether all this angst is worth the end result when the path of least resistance will yield an equally functional result. The answer to that depends, in part, on how much other stuff you have already done. But before you do more things don't forget that the basic device needs to be in optimum working condition (like not eating battery) first.
Click to expand...
Click to collapse
I will Authenticate using DeviceRegistrator and see if it works. The Catch 22 is that if I revert to Factory and then register the device I might have a problem with the 1.2.2 update I want to avoid (but yes, I realize at this point my aversion to 1.2.2 is basically irrational.) So I will try this approach first and report back. I will double check to see if the Nook Device shows up in my B&N account too, and I'll report again.
I agree 100% about putting the device in a sound baseline state before installing a lot into it. I'm documenting all that I do, and when I reach that state I'll create a thread about it. Hopefully it can be of use to someone down the road, because I do see new NST units being bought still every week in eBay.
I was relieved that ADB over USB was already enabled by installing NookManager and that I only needed to create a couple of files in my Ubuntu machine for it to work.

Winston S. said:
I was relieved that ADB over USB was already enabled by installing NookManager and that I only needed to create a couple of files in my Ubuntu machine for it to work.
Click to expand...
Click to collapse
That's actually news to me. I had thought the flag for WiFi ADB was set. I've never tried USB.

nmyshkin said:
That's actually news to me. I had thought the flag for WiFi ADB was set. I've never tried USB.
Click to expand...
Click to collapse
Yes, apparently ADB Konnect is set up so that if you start ADB Wireless it sets the flag, and then unsets it. I just tried ADB through Wireless and it also works.
To update on the DeviceRegistrator, I tried to Authenticate the Device and it didn't work (I got a banner saying that the operation is no longer supported.) So it looks like I will need to restore to Factory, register, and then root (which defeats the purpose of disabling OTA updates, as I can't do that until I root.)

@nmyshkin, is resetting the Nook to factory by using "Erase & Deregister Device" option in the stock Nook Settings the same as resetting to factory.zip from NookManager or holding the two Page Back hardware buttons on startup?
I reset mine using the "Erase & Deregister Device" menu option, and then registered and rooted it again, but still I am having problems with CoolReader (I am using the cr3_0_49_13.apk posted in the relevant thread.) Basically, there are no options to set the refresh interval where they should be, and the Options interface is black. Somebody mentioned this as well but they fixed it by restoring to factory, so I'm wondering what the deal is. Is this the only version of CoolReader people use with the NST?

Winston S. said:
@nmyshkin, is resetting the Nook to factory by using "Erase & Deregister Device" option in the stock Nook Settings the same as resetting to factory.zip from NookManager or holding the two Page Back hardware buttons on startup?
I reset mine using the "Erase & Deregister Device" menu option, and then registered and rooted it again, but still I am having problems with CoolReader (I am using the cr3_0_49_13.apk posted in the relevant thread.) Basically, there are no options to set the refresh interval where they should be, and the Options interface is black. Somebody mentioned this as well but they fixed it by restoring to factory, so I'm wondering what the deal is. Is this the only version of CoolReader people use with the NST?
Click to expand...
Click to collapse
No, erase and deregister does just that. It removes your account info and settings. The factory reset is an actual reimaging of the device from the protected onboard image. This can be done with the two button technique, NookManager or eight failed boot attempts.
I'm afraid I can't help much with CoolReader. I once had a version installed but found it had way too many settings for me. I ended up using only the screensaver/book cover option but that was pretty silly and I eventually got rid of and wrote my own app for that.
I located the version for the other fellow, but that's the extent of my knowledge. I'll try it in a bit and see what you're talking about.

nmyshkin said:
No, erase and deregister does just that. It removes your account info and settings. The factory reset is an actual reimaging of the device from the protected onboard image. This can be done with the two button technique, NookManager or eight failed boot attempts.
I'm afraid I can't help much with CoolReader. I once had a version installed but found it had way too many settings for me. I ended up using only the screensaver/book cover option but that was pretty silly and I eventually got rid of and wrote my own app for that.
I located the version for the other fellow, but that's the extent of my knowledge. I'll try it in a bit and see what you're talking about.
Click to expand...
Click to collapse
Please, don't waste any time with CoolReader. As usual, you saved the day. I'll reimage the device using the correct procedure, as I mistakenly believed this is what the Erase and Deregister option did. I think this will take care of the CoolReader weirdness, and if not I have found that NoRefresh works remarkably well with it anyway. Thank you!

Winston S. said:
Please, don't waste any time with CoolReader. As usual, you saved the day. I'll reimage the device using the correct procedure, as I mistakenly believed this is what the Erase and Deregister option did. I think this will take care of the CoolReader weirdness, and if not I have found that NoRefresh works remarkably well with it anyway. Thank you!
Click to expand...
Click to collapse
Mmm.....I see nothing in that version of CoolReader thats looks anything like it was adapted for the NST. I got that version from a e-book blog post link so shame on me for passing along bogus stuff. It's definitely NOT the version I once had installed (whatever that was...). The current market version is incompatible and the "new" CoolReader GL installs but does not run. I took a look at the CR home at SourceForge and there are many versions available there but it would be trial-and-error with them--and maybe there is no magic bullet. If you search for "CoolReader" on the forum you will find a variety of references. In some lists of "working" apps there are version numbers. Tracking down one of those might be a start.

nmyshkin said:
Mmm.....I see nothing in that version of CoolReader thats looks anything like it was adapted for the NST. I got that version from a e-book blog post link so shame on me for passing along bogus stuff. It's definitely NOT the version I once had installed (whatever that was...). The current market version is incompatible and the "new" CoolReader GL installs but does not run. I took a look at the CR home at SourceForge and there are many versions available there but it would be trial-and-error with them--and maybe there is no magic bullet. If you search for "CoolReader" on the forum you will find a variety of references. In some lists of "working" apps there are version numbers. Tracking down one of those might be a start.
Click to expand...
Click to collapse
Thank you for looking at this. I am a little confused, because you helped @ALinkToTao who was having problems with it, and he seems to imply that the version linked here which you referred him to ended up working for him..
So I'm just going to write that off to him being confused about the version he ended up installing. I will see if I find something that works, thanks again.

Winston S. said:
Thank you for looking at this. I am a little confused, because you helped @ALinkToTao who was having problems with it, and he seems to imply that the version linked here which you referred him to ended up working for him..
So I'm just going to write that off to him being confused about the version he ended up installing. I will see if I find something that works, thanks again.
Click to expand...
Click to collapse
Yeah, so I need to redeem myself there. In my lame defense, I was just going with what was posted here: https://blog.the-ebook-reader.com/2...artial-refresh-and-page-button-support-video/
Clearly that is bogus. So I checked out @wozhere's listed working version, or something close.
I think the place to start is with the 3.1.2 series from the SourceForge home of CoolReader. The attached version looks a lot more like what I remember and has screen refresh options (only visible as settings while viewing a book).
There were many more options on the version I once had, so this one is a starting point only.