I don't know how I missed this!
Android Rootkit is just a phone call away
Now, hopefully after Defcon, the details will go public, and since the Rogers Dream won't be patched (that's what you get for never giving us OTA updates), I'm sure it'll be adapted into a local exploit as well.
"This could be done by building the rootkit into a rogue application sold via the Android Market, or by exploiting a new, unpatched bug in Android's Linux kernel that could allow the program to be installed."
** actually, it would require BOTH.
And at this time, there ARE NO known kernel bugs affecting Android's kernel.
The old "1-click-root" app demonstrated this kind of thing, and DID exploit a kernel bug, which HAS SINCE BEEN PATCHED.
This thing can ONLY hurt a ROOTED phone, and even then, the su app will pop up saying "gee, this app wants root, should we let him?"
lbcoder said:
"This could be done by building the rootkit into a rogue application sold via the Android Market, or by exploiting a new, unpatched bug in Android's Linux kernel that could allow the program to be installed."
** actually, it would require BOTH.
And at this time, there ARE NO known kernel bugs affecting Android's kernel.
The old "1-click-root" app demonstrated this kind of thing, and DID exploit a kernel bug, which HAS SINCE BEEN PATCHED.
This thing can ONLY hurt a ROOTED phone, and even then, the su app will pop up saying "gee, this app wants root, should we let him?"
Click to expand...
Click to collapse
I believe flashrec exploited the sock_sendpage() glitch. It may be possible that they have discovered a new exploit similar to the sock_sendpage, and simply haven't made it public. Remember, that one was present since 2001. It can be built into any apk, and instead of giving a shell root access, it can run background processes with a superuser permission.
Just food for thought.
Which will easily be fixed with a wipe and reflash if it -does- happen.
...right?
r3s-rt said:
Which will easily be fixed with a wipe and reflash if it -does- happen.
...right?
Click to expand...
Click to collapse
Yes, as long as the rootkit doesn't block fastboot and ADB
I'm pretty sure it can't stop you from getting to recovery, though? Either way - this would be just more of a pain in the ass for me.
However, some people are genius enough to store crucial information on their phone such as S.S. numbers and credit card numbers, and people are dumb enough to install this and give it su permissions. :/
Related
Any recommendations for a restart button? I'm too lazy to power off then power on the device.
Sent from my A500 using XDA Premium App
Quick Boot!! Nice app..
Does that actually reboo the tab?
I thought all it did was kill all running apps to 'simulate' a reboot.
It DOES need root access though (and I've not yet seen any point to rooting the A500).
Fluffbutt said:
Does that actually reboo the tab?
I thought all it did was kill all running apps to 'simulate' a reboot.
It DOES need root access though (and I've not yet seen any point to rooting the A500).
Click to expand...
Click to collapse
It definitely reboots! The pro version has a mode that "simulates" a reboot, similar to what you're talking about.
Fluffbutt said:
It DOES need root access though (and I've not yet seen any point to rooting the A500).
Click to expand...
Click to collapse
Although it's not the subject, I really wanted to note that rooting A500 does worth it for sure. I'm using ADFree, ClockSync, Autokiller, File Expert, NTFS mount, Root uninstaller and a few more root-required applications which add some epic user experience. Just consider unrooting your device back before installing any updates or system modifications. Cheers.
anusthegreat said:
Although it's not the subject, I really wanted to note that rooting A500 does worth it for sure. I'm using ADFree, ClockSync, Autokiller, File Expert, NTFS mount, Root uninstaller and a few more root-required applications which add some epic user experience. Just consider unrooting your device back before installing any updates or system modifications. Cheers.
Click to expand...
Click to collapse
Yes, i wasn't trying to bring it up as a subject, just asking if rooting it was worth it for the reboot app.
I can see some people might want root, and the ADFree is probably one good reason. The rest don't interest me at all.
I used to have a custom Darky's ROM on my previous Samsung Galaxy S, I had an extra power-off menu letting me choose Reboot or Shutdown or even Recovery or Download modes. Obviously, I was using the feature to reboot the device pretty often; I'd like to have a one-button widget rebooting my device properly.
Also, about the apps which don't interest u..
*my tablet is usually about +/-2,5 sec every time I shut it down, not reboot;
*autokiller helps to save memory, at least I can be sure I don't have to start a game level again because of an e-mail or something like this;
*a decent root file explorer letting you see hidden system directories is a must just because any minimal and safe modifications do improve performance
Hello,
If I root my stock Aconia will it pose issues later when official OTA updates will be pushed? I like honeycomb as it is and don't want to have custom ROM installed but want it to be rooted.
No, rooting won't have any affect on updates. However, if you remove any stock applications / games then yes, it could (will definitely) very well cause updates to fail - otherwise, happy rooting!
I believe it won't prevent you from getting the OTA updates, but be aware that whatever incremental update you do, you lose root access and you have to root once again either with the released methods or wait for a new one to be developed (some opennings for the root process might get patched with the updates, so developers look for new creative ways to root the device).
caution after root
Rooting will not stop ota.if you do root.
Install Acer recovery/clockwork mod make good. Backups.and any system files you alter bee sure to jus5t rename and save a backup of original files.as altering files even game preloaded on your tab. Will cause issues on installing ota updates.
Go cautiously and educated and you will be fine.there is a awesome bunch of talented people in here.
They deserve our most given respect. Thanks xda developers.and the developers and advanced users here.
Hugged to all.
erica_renee said:
Rooting will not stop ota.if you do root.
Install Acer recovery/clockwork mod make good. Backups.and any system files you alter bee sure to jus5t rename and save a backup of original files.as altering files even game preloaded on your tab. Will cause issues on installing ota updates.
Go cautiously and educated and you will be fine.there is a awesome bunch of talented people in here.
They deserve our most given respect. Thanks xda developers.and the developers and advanced users here.
Hugged to all.
Click to expand...
Click to collapse
I don't understand why do you want to have custom ROM for Honeycomb? I understand if you want it for phones becouse phones are frequently full bloat (much more then tablet), restrict tethering, very slow to update rollout due to vendor QA etc. But Tablet seems to me good from all this points of view the way it comes from a store. The only drawback is lack of root.
Some of the ROMs port over system-specific apps and libraries. For instance, the 'stock' Acer libraries won't support Netflix streaming; replace one of the files with a lib from a different tablet and bingo! Technically you can do the same thing using Root Explorer etc.; consider the various ROMs as pre-packaged replacements.
I'm personally a vanilla fan, although I will probably experiment with some 3rd party kernels in the future (not a full ROM replacement) because I like seeing how fast I can push my CPU without crashes
And as stated above, if you do anything with any of the pre-installed apps etc. once rooted (say, replace the wpa_supplicant file with one that supports ad-hoc networking) be sure to keep a backup of the original in case the next OTA checks that file.
artisticcheese said:
I don't understand why do you want to have custom ROM for Honeycomb? I understand if you want it for phones becouse phones are frequently full bloat (much more then tablet), restrict tethering, very slow to update rollout due to vendor QA etc. But Tablet seems to me good from all this points of view the way it comes from a store. The only drawback is lack of root.
Click to expand...
Click to collapse
I have no custom rom installed its just currently the easier way to Do a system backup.something Acer should have giving us.but that's another topic.the cwr recovery will let you backup your system.
erica_renee said:
I have no custom rom installed its just currently the easier way to Do a system backup.something Acer should have giving us.but that's another topic.the cwr recovery will let you backup your system.
Click to expand...
Click to collapse
MyBackupRoot will do that as well as Titanium backup without modifying boot loader and having possibility of bricking device in the process.
Ok, they keep updating and breaking root. I hear droidwall will block it.
But what is the name I should be blocking?
Or is there a better way to stop auto updating?
Delete OTACERTS.zip in system/etc/security. You must enable r/w and have root.
When I did It, it downloaded the update in front of me but didn't update. Then I deleted the update. Now i'm still on 6.2.1 and Loving It.
Molinari said:
Ok, they keep updating and breaking root. I hear droidwall will block it.
But what is the name I should be blocking?
Or is there a better way to stop auto updating?
Click to expand...
Click to collapse
I did the otacerts.zip thing mentioned above (moved to sdcard and renamed to otacerts.bak).
However, just to be safe I am also using droidwall. With droidwall, I started out by blocking everything (default) and then unblocked things when they would not work (use the log to see what is being blocked). Be sure to actually enable the blocking and the logs (they are off by default). Some things you can be unblocked ahead of time like Market and Browser. The only potential issue with using droidblocker is that whatever is used for the OTA update might also be used by something else that needs to be unblocked.
mark_a_l said:
I did the otacerts.zip thing mentioned above (moved to sdcard and renamed to otacerts.bak).
However, just to be safe I am also using droidwall. With droidwall, I started out by blocking everything (default) and then unblocked things when they would not work (use the log to see what is being blocked). Be sure to actually enable the blocking and the logs (they are off by default). Some things you can be unblocked ahead of time like Market and Browser. The only potential issue with using droidblocker is that whatever is used for the OTA update might also be used by something else that needs to be unblocked.
Click to expand...
Click to collapse
Droidwall Doesnt work, I tried that on the 6.1 to 6.2 update because I did not want to risk a potential update. That was before we knew of the ota updates.
iroctheworld said:
Droidwall Doesnt work, I tried that on the 6.1 to 6.2 update because I did not want to risk a potential update. That was before we knew of the ota updates.
Click to expand...
Click to collapse
What were you blocking? I've only got about 6 things on my white list (not blocked). Half are market related. In any case even if it doesn't work for OTA updates, I find some apps to be a bit too 'chatty' (looking at the logs). So it does work at blocking 'unnecessary' wifi traffic.
Thanks for the rename tip!
I am still avoiding the 6.2.2 update (only time can tell, last time mine was updated about 1 week after the first posting about forced updates ...)
I am running the rooted version of 6.2.1. I flashed this after losing root from the 6.2.1 forced update.
This time I only did two "mods" for protection -
(1) un-register from Amazon (actually I never register during ROM installation)
(2) use Droidwall
I dunno which one will make me survive the forced update, but I suspect it may / will be #(1).
I only allow a few things to go through Droidwall, most of them are 3rd party apps' names. The only two additional processes necessary for normal functions are:
(1) downloads, media storage, DRM protected content storage, download manager (needed for Market downloads)
(2) search (for Google search)
The one I always worry about in Droidwall is obviously #(1). I certainly do not let things like Amazon device client platform (ADCP) to go through!
This is just my Droidwall setup. People using other apps may need to allow other Android processes through therefore I cannot guarantee Amazon update won't sneak through that way.
I only know about the otacerts.zip when I revisited the forum yesterday afte reading elsewhere about the new OTA update. This time I won't modify this file on purpose.
(fingers crossed for me, I am not out of the woods yet)
P.S. Feb 2nd and I am still clean, looks like I dodged it!
Here's how I have Android Pay working on my rooted 5x:
-Starting from stock 6.01 (Some other ROMs are reported working. Most importantly it needs to be a ROM where Android Pay was working prior to systemless root)
-Flashed systemless SuperSU 2.67 from TWRP (See UPDATE 3 below to make sure you have a systemless install)
-run "adb shell"
-from adb shell run "su"
-from adb shell run "chmod 751 /su/bin"
Have fun!
With this change the checks in SafetyNet Helper are passing and I can add cards and make purchases with Android Pay. The change is surviving reboots and doesn't require messing with any settings in the SuperSU app to enable/disable root.
UPDATE 1: As others have pointed out this permissions change can also be done with a file manager like Root Explorer that lets you change permissions. Probably easier for most than ADB commands.
UPDATE 2: Some people haven't been able to get Android Pay working with just this permission change. Check if you have /su/xbin_bind - deleting this may get it working. Thanks to @bobby janow and @CSX321 for pointing this out.
UPDATE 3: To clarify on the systemless SuperSU installation (this seems to be a trouble point for some) - there are settings that need to be configured for the SuperSU install to make it systemless and to not create the system/xbin binding. The installer reads these options from a file on /data/. Since you don't have root yet you need write these settings over ADB in TWRP. If you don't see the /su/ directory, you probably don't have a systemless install. In that case you can go back to stock (restore system, boot, and vendor partitions). Then, when you reinstall SuperSU, these are the commands you need to send from your TWRP ADB shell:
Code:
echo SYSTEMLESS=true>>/data/.supersu
echo BINDSYSTEMXBIN=false>>/data/.supersu
Once you've got SuperSU installed, change the permissions of /su/bin/ (either chmod or using a file explorer)
You can check Android pay by simply trying to add a card and you'll know right away.
buru898 said:
You can check Android pay by simply trying to add a card and you'll know right away.
Click to expand...
Click to collapse
Yeah just removed my card and added it again. Went through all the contacting bank stuff and it worked. I think this is the real deal.
Try and make a purchase and report back! Thanks though!
Ya sometimes you can add a card but fail a purchase. Adding the card isn't a sure thing
jgummeson said:
Yeah just removed my card and added it again. Went through all the contacting bank stuff and it worked. I think this is the real deal.
Click to expand...
Click to collapse
Hmm now I want test this out. Need to flash ROM again.
If you're able to try a purchase, please let us know.
buru898 said:
Hmm now I want test this out. Need to flash ROM again.
If you're able to try a purchase, please let us know.
Click to expand...
Click to collapse
That's the only trouble with Android Pay - no one takes it. I'll see if I can stop by Trader Joe's tonight and pick something up. They're the only place around here I know of that takes it.
jgummeson said:
That's the only trouble with Android Pay - no one takes it. I'll see if I can stop by Trader Joe's tonight and pick something up. They're the only place around here I know of that takes it.
Click to expand...
Click to collapse
Don't forget anywhere you see the NFC lines symbol should work. I've even seen some that didn't have the symbol but still had an NFC scanner.
Sent from my Nexus 7 using Tapatalk
Yep Android Pay worked for a purchase. Just chmod your /su/bin/ directory to 751. Works for me on stock with systemless root and I imagine it may work on other ROMs that used to work until the recent change in the SafetyNet checks.
Running Chroma with SU 2.66. After running those commands AP will let me at least add a card, which I couldn't do before those commands (get can't verify android error). Will try testing in store tomorrow hopefully.
This is great news!
Tell the reddit people and get famous!
Does anyone know for certain if passing through SafetyNet Helper means it'll always work with pay?
smac7 said:
Does anyone know for certain if passing through SafetyNet Helper means it'll always work with pay?
Click to expand...
Click to collapse
Always? No. Google is actively trying to keep Android Pay safe in the eyes of banks and credit card companies, whether that is by blocking system/system-less root, or making adjustments server side to prevent workarounds that could potentially exploit the Android Pay experience.
Sent from my Nexus 5X using Tapatalk
SlimSnoopOS said:
Always? No. Google is actively trying to keep Android Pay safe in the eyes of banks and credit card companies, whether that is by blocking system/system-less root, or making adjustments server side to prevent workarounds that could potentially exploit the Android Pay experience.
Sent from my Nexus 5X using Tapatalk
Click to expand...
Click to collapse
Well, i know google is trying to lock us out, but i thought safetynet was what Android pay uses to verify the the phone is indeed "safe". If the previous statement is correct, it would stand to reason that if it passes through safetynet helper then it'll also pass through android pay.
smac7 said:
Well, i know google is trying to lock us out, but i thought safetynet was what Android pay uses to verify the the phone is indeed "safe". If the previous statement is correct, it would stand to reason that if it passes through safetynet helper then it'll also pass through android pay.
Click to expand...
Click to collapse
That API is probably the best indicator of success right now but I could also see that changing if Google decides it needs to be more thorough in its approach
Sent from my Nexus 5X using Tapatalk
buru898 said:
This is great news!
Tell the reddit people and get famous!
Click to expand...
Click to collapse
Yeah I posted it on the Reddit and it sank to the bottom and everyone ignored it. No fame for me. I'll have to settle for Android Pay.
jgummeson said:
Yeah I posted it on the Reddit and it sank to the bottom and everyone ignored it. No fame for me. I'll have to settle for Android Pay.
Click to expand...
Click to collapse
Well you could always try having it posted to the xda portal and replying to this thread.
https://www.reddit.com/r/Android/comments/43bl05/newest_safetynet_check_detects_systemless_root/
buru898 said:
Well you could always try having it posted to the xda portal and replying to this thread.
https://www.reddit.com/r/Android/comments/43bl05/newest_safetynet_check_detects_systemless_root/
Click to expand...
Click to collapse
Yeah that's where I posted it - it's a comment way down on the bottom. Maybe I just don't know how to Reddit... Well started a new thread on there. Hopefully someone is paying attention this time.
jgummeson said:
Yeah that's where I posted it - it's a comment way down on the bottom. Maybe I just don't know how to Reddit... Well started a new thread on there. Hopefully someone is paying attention this time.
Click to expand...
Click to collapse
You just have to wait for somebody else to repost it:
https://www.reddit.com/r/Android/comments/44be69/android_pay_working_with_root/
jgummeson said:
Let me know if anyone else can confirm this works.
Click to expand...
Click to collapse
Yep! I just got a Mt. Dew from the machine at work. I did have to delete the card, reboot, and add the card back again. Pay seems to remember if it's ever failed with a card, and refuse to work with that card until you delete and re-add it.
In preparation for the impending upgrade to Android 6 Marshmallow, I'm trying an experiment on my Android 5 based Zenfone 2. I'm going to see how annoying it is to give up root. The first thing I did on my first android phone was root it, so I've only every used rooted Android devices.
Prologue:
Root on Android 6 (usually) requires an unlocked bootloader, because root is achieved by modifying the boot image to inject su into the system. That way the system image is left unmodified and can continue to pass dm-verity checks.
At the moment, there does not appear to be anyway on the Zenfone 2 to unlock the Marshmallow beta bootloader, and it also appears to relock any unlocked bootloader. In fact, the droidboot binary in the droidboot.img of the Marshmallow beta contains the strings rm -rf /factory/asuskey and rm -rf /factory/asussignature. droidboot also contains the strings unlock successfully...reboot after 5 seconds and **** Unlock bootloader? **** as well as other strings referring to unlock (droidboot from the .184 Lollipop also has those strings). So, my hope is that there is a simple way to unlock the bootloader, which will be revealed by Asus, or discovered by somebody.
My thought is that worst case those of us who want root will use an unlockable Lollipop bootloader with a Cyanogenmod 13.1 based ROM created with updates from the Asus Marshmallow source code.
Experiment:
I've removed Xposed and SuperSU from my phone. Making it stock Android 5. I'm documenting here the functionality that I lose. The first goal is for my own amusement to keep a log of what I'm giving up.
The second goal, and probably the major one, is to solicit suggestions on what can be done to replace the functionality I'm losing.
What I'm giving up:
AdAway - No system wide ad blocking. Firefox with uBlock Origin should cover blocking ads on the web. I usually buy apps I use frequently, but I'll have to see which ones are annoying with ads. I'm aware of the VPN based ad blocking methods, but I'll have to wait and see if it comes to that.
AFWall+ - Using root to improve security... I mostly use this to prevent some apps from using mobile data, and to prevent some apps from gaining network access at all.
BetterBatteryStatus - It works in non-root mode, but not as well.
BusyBox - Without root, there isn't much need for this anyway.
Cryptfs Password - Once again, security is harmed by removing root. This allowed my encryption pin to be different (and much longer) than my screen lock pin. I don't want to type 10 digits to unlock my screen, but it's fine for booting.
Greenify - This definitely kept some aps in check, but perhaps Asus' Auto-Start Manager will be able to replace it.
GSam Battery Monitor - Like BetterBatteryStatus, this had a root component to provide more information.
Kernel Adiutor - For some reason my phone seemed to only go to 1.8ghz instead of 2.3ghz, so I used this to fix it.
Linux Deploy - I never used the Linux chroot image for much, but it was a cute toy.
Secure Settings - This let tasker automate adjusting some things which require root to change.
Titanium Backup - This is a massive loss in functionality. Simply having backups is tremendously important. The ability to freeze unwanted system apps is also nice. I can reload many of my apps from Google, but not all of them bother to save their settings in the Google backup. Ohh, the bloat!
Trimmer (fstrim) - Probably not really necessary, anyway.
Xposed
Amplify - It saved me lots of wakeups, but I don't know if it really did much to increase battery life.
Fix Lollipop Memory Leak - I don't know if this did anything, either.
GravityBox [LP] - I didn't tweak too much, but what I did change was really useful.
NetStrength - I like replacing my wifi bars with useful information.
ProtectMyPrivacy - The permission settings in Marshmallow would make this obsolete anyway.
YouTube AdAway - Nice, but not required.
What I'm gaining:
Android Pay - I guess I can play with this now.
AFWall+ - Using root to improve security... I mostly use this to prevent some apps from using mobile data, and to prevent some apps from gaining network access at all.
Click to expand...
Click to collapse
Asus has integrated a firewall iptables recent months.
Asus mobile manager -> User Data -> Restrict (bottom of screen)
For the rest, no root is to accept to take along twice monitoring tools of an advertising billboard.
Keep in mind that Google is an advertising agency that is desperate to earn money, including harassment to get the maximum information.
Its purpose, despite what he claims, is not to improve people's lives, but his bank account.
Android is a disguised tools for Google, not for the people who is a commodity to be exploited.
I'm gonna miss Adaway and Afwall+ the most. Afwall+ is much better than the Asus built in firewall. You can disable net access by default for newly installed app. You are notified to set firewall rules when you install an app. You can filter apps to be set. If only Asus could provide a such a bunch of feature for their firewall, I won't miss root so much.
Sent from my Asus Zenfone 2 using XDA Labs
IDEDALE said:
Asus has integrated a firewall iptables recent months.
Asus mobile manager -> User Data -> Restrict (bottom of screen)
Click to expand...
Click to collapse
Thanks for the info about the functionality in Asus Mobile Manager, I didn't know that.
As far as Adaway goes, try this https://block-this.com
Sent from my ASUS_Z00A using Tapatalk
IDEDALE said:
Asus has integrated a firewall iptables recent months.
Asus mobile manager -> User Data -> Restrict (bottom of screen)
For the rest, no root is to accept to take along twice monitoring tools of an advertising billboard.
Keep in mind that Google is an advertising agency that is desperate to earn money, including harassment to get the maximum information.
Its purpose, despite what he claims, is not to improve people's lives, but his bank account.
Android is a disguised tools for Google, not for the people who is a commodity to be exploited.
Click to expand...
Click to collapse
Agree with most of that... unfortunately the ASUS mobile manager "firewall" doesn't work any more on the current marshmallow beta.
It's still there, but it seems not to work for blocking apps.
The new app permission system in MM may be used to prevent apps from connecting around, in theory at least, but I'm not sure how effective that is.
This phone without root absolutely sucks. There's a thread on the ASUS forum, guy has links to pre rooted system images but I haven't tried it.
http://www.asus.com/zentalk/thread-39487-1-1.html
Sent from my ASUS_Z00AD using XDA-Developers mobile app
The thread mentioned was opened in September '15... Didn't try downloading the files but can't imagine that there's a pre-rooted file out there already. Somebody would have known and told us, I guess
If anyone tried and it works, may you leave a line!
sent from my Binford Z00AD using tapatalk
nfc expert said:
if you want stop ad without root, you can try this : https://block-this.com/
Click to expand...
Click to collapse
kenbo111 said:
As far as Adaway goes, try this https://block-this.com
Click to expand...
Click to collapse
There are several other VPN based ad blockers as well. AdClear, AdGuard, and I think some more.
I played with some of them when they first started coming out, but always returned to the host file based blocker, because it was easy and worked fine with root. I think the phone has plenty of RAM and CPU to run these VPN ones, but I haven't been annoyed to try them again. So far uBlock Origin in Firefox has been fine. In the almost two days since unrooting I've used one app which shows me ads.
IDEDALE said:
Asus has integrated a firewall iptables recent months.
Asus mobile manager -> User Data -> Restrict (bottom of screen)
Click to expand...
Click to collapse
Thanks for the tip, I didn't know about it. This was easy enough to setup, even if it doesn't have as many features as AFWall+. I haven't tested to make sure it works.
My idea to get root on Asus' Marshmallow release is to install just the system, but keep the unlocked bootloader and ifwi from Lollipop. It should be easy enough to modify the updater script to only flash the system and boot image, while leaving the bootloader and ifwi alone. I don't know if that will work, or if the system will crash when it finds an old ifwi, or if the bootloader will fail to load the new system. With an unlocked bootloader, root is trivial.
As long as the bootloader is in place, it should be easy to recover from a broken system.
Don't take my word for it though, these are just ideas, and I'm not ready to try them yet. My warranty is over at the end of the month, so I'll unlock my bootloader then.