Related
In this method you will be able to activate your tethering hotspot only for a temporary period of time. First hotspot activate will work fine but once you turn it off you will be prompted with the entitlement check when you try to reactivate the hotspot. You will need to repeat the process again in order to bypass the entitlement check. So with that in mind lets begin.
(I AM NOT RESPONSIBLE FOR VERIZONS GETTING UPSET FOR YOU USING THIS FREE HOTSPOT!!!!)
In other words try to keep this method under VERIZONS knowledge and you should be fine.
Requirements:
You will need to have done CrashXXL`s root method to have a rooted Droid.
Then once you have a rooted device download SQlite editor which can be purchased on the Gioogle Playstore.
(NOTE: i will not post any download links for SQlite Editor due to XDA rules.)
Step1: Open Rsqlite editor then go to apps then Settings storage with the two tools icon. Now from there go to settings.db . Now go to secure and you`ll see a list of words and ids as well as value columns.
Step2: Change these exact values to the values listed below.
-dun_nat_enabled= enabled
-tether_reverse_nat_enabled= enabled
-entitlement_check= 0
-USB_entitlement_check= 0
-Network_settings_on_boot= 1
-APN_CHECK_STATE= 1
APN check state is the most important.
Step3: Once the values are changed reboot your device and you will be able to use the hotspot once then once you deactivate the hotspot itll check for entitlement check. So for now this is a temperary Hotspot method! Enjoy
My YouTube video tutorial: https://m.youtube.com/watch?v=A0Xc_z6vYXA
Easier method
This is only my first post, and I know that I might be missing something important, but there is an easier method to activate tethering for this device and firmware. While the xt1080 is not supported officially by kingroot, the app will grant temporary and limited root permissions (no /system access). This is enough to get the entitlement bypass app working on the device. I have attached the apks for the entitlement bypass and kingroot apps below. You can download the latest version of Kingroot from the official website. The entitlement bypass app will only run successfully once the device has been temporarily rooted by kingroot. While the root will not last, the bypass of the entitlement check for the tethering hotspot should remain in effect, until the next reboot. You should be able to use the hotspot without any problems until that point, at which time you will have to rerun the Kingroot app. This method has worked for me for months. I am on an xt1080 Droid Maxx running 4.4.4 SU6-7.2. Nothing else is required for this method. Although, the initial root may require a restart/retry or two. I hope this helps.
jamesbrogan85 said:
This is only my first post, and I know that I might be missing something important, but there is an easier method to activate tethering for this device and firmware. While the xt1080 is not supported officially by kingroot, the app will grant temporary and limited root permissions (no /system access). This is enough to get the entitlement bypass app working on the device. I have attached the apks for the entitlement bypass and kingroot apps below. You can download the latest version of Kingroot from the official website. The entitlement bypass app will only run successfully once the device has been temporarily rooted by kingroot. While the root will not last, the bypass of the entitlement check for the tethering hotspot should remain in effect, until the next reboot. You should be able to use the hotspot without any problems until that point, at which time you will have to rerun the Kingroot app. This method has worked for me for months. I am on an xt1080 Droid Maxx running 4.4.4 SU6-7.2. Nothing else is required for this method. Although, the initial root may require a restart/retry or two. I hope this helps.
Click to expand...
Click to collapse
I've spent a lengthy period of time trying to get tethering to work on a broken screen MAXX, because I refuse to finance a new phone to Verizon. This entitlement app worked perfectly. So I am not able to tether the connection to a prepaid phone and forward my calls to the prepaid device and use my TWC Phone2go.
Thank you
Dear forum,
Long time no talk! I have been able to get "root" for our phones on G925VVRU4BOG7, which anyone can downgrade to. The catch is that even with /system mounted as rw, I am unable to write to it directly through most conventional means. (I can write to /data, though, which means i can patch dalvik-cache, which means my mods are coming ) However, I am able to still write to it using another, more complicated way (I can go into more detail for those interested), as a whole. Here's where you come in-- is anyone still full-rooted? If so, please message me as soon as possible! I may be able to have users who are on newer builds downgrade to older builds and get su properly installed, then manually upgrade back up to the later builds again!
If you are rooted still, all i'm going to have you do is perform this command:
Code:
su
dd if=/dev/block/platform/15570000.ufs/by-name/SYSTEM bs=4096 of=/sdcard/system.img
Then send me that system.img file on your sdcard! It'll be pretty big, so you can zip it or .7z (7-zip), whatever you'd like to do.
I will also need what build you are on. You can just send me your Build number within "Settings->About phone".
First one who does it gets credits on the official release thread i'll make, when I get a procedure down that people can follow!
Thanks!
-Trailblazer101
i have an s6 edge on 5.0.2 rooted. Would that be of help?
Did you get the system.img file? I really wish I could help you. I have this phone on 6.0.1 and stuck without root, but the thing is I really need the root because I bought it used, worked fine the first few days, then didn't get any signal (turns out that it was reported as stolen and of course the IMEI got blacklisted; I tried to contact the seller but he was gone, and his ebay account deleted, so basicly I'm stucked with a ' 5.1" tablet' . I got scammed :/ )
I would be very grateful if you could explain how did you get root on G925VVRU4BOG7 . I know that you want the file mentioned for creating some kind of universal root for the phone, but right now I'm kind of desperate and need root as soon as possible to fix my IMEI issue and I would follow your steps if you made a tutorial.
Thank you very much!
trailblazer101 said:
Dear forum,
Long time no talk! I have been able to get "root" for our phones on G925VVRU4BOG7, which anyone can downgrade to. The catch is that even with /system mounted as rw, I am unable to write to it directly through most conventional means. (I can write to /data, though, which means i can patch dalvik-cache, which means my mods are coming ) However, I am able to still write to it using another, more complicated way (I can go into more detail for those interested), as a whole. Here's where you come in-- is anyone still full-rooted? If so, please message me as soon as possible! I may be able to have users who are on newer builds downgrade to older builds and get su properly installed, then manually upgrade back up to the later builds again!
If you are rooted still, all i'm going to have you do is perform this command:
Code:
su
dd if=/dev/block/platform/15570000.ufs/by-name/SYSTEM bs=4096 of=/sdcard/system.img
Then send me that system.img file on your sdcard! It'll be pretty big, so you can zip it or .7z (7-zip), whatever you'd like to do.
I will also need what build you are on. You can just send me your Build number within "Settings->About phone".
First one who does it gets credits on the official release thread i'll make, when I get a procedure down that people can follow!
Thanks!
-Trailblazer101
Click to expand...
Click to collapse
I am currently running on A0E2 using your rooted rom for this phone. It runs great....except I tried flashing xposed framework using Flashfire and it of course failed...due to the fact that xposed only works on 5.1.1 or above...sucks we are in such a catch 22 with our devices...although I'm happy because I am still rooted.. Anyway...I set up ADB and entered that command you posted and it worked...I just don't know where the storage location of the system.img file is for me to transfer to my PC, 7zip, and send to you. Any help would be excellent....as I desperately want to run xposed framework on my device....but am stuck on 5.0.2
r0ckinb0i said:
I am currently running on A0E2 using your rooted rom for this phone. It runs great....except I tried flashing xposed framework using Flashfire and it of course failed...due to the fact that xposed only works on 5.1.1 or above...sucks we are in such a catch 22 with our devices...although I'm happy because I am still rooted.. Anyway...I set up ADB and entered that command you posted and it worked...I just don't know where the storage location of the system.img file is for me to transfer to my PC, 7zip, and send to you. Any help would be excellent....as I desperately want to run xposed framework on my device....but am stuck on 5.0.2
Click to expand...
Click to collapse
Looking at the last part of the command and if it ran successfully, it should be in /sdcard. Did you ever find it?
gabes100 said:
Looking at the last part of the command and if it ran successfully, it should be in /sdcard. Did you ever find it?
Click to expand...
Click to collapse
Thank you I found it...I'm new to command prompt although I am learning quickly. I found it. I just need to load it onto my computer and compress it so I can send it to Trailblazer. I will do that tomorrow night when I get back home.
I have the img on my computer. It is 4.3G. How do I get it to Trailblazer? Google Drive? EDIT: it is 4.58GB. I am uploading now to google drive, it will an hour
Hi Trailblazer,
Here is a link to system.img:
https :// drive google com / open?id=0B-j3XfGrnj9PbUdwaml5eERvbFU
I am too new to post links the correct way.
Are there any updates on this topic? When I first saw this thread last week, It got me thinking about what a Tethered Root (Temporary/Semi - Root) would still be capable of doing for those of us still on Official Firmware in this day and age.
And really it occurred to me at that moment, that if we could just attain a Root Shell even if it was only for 60 seconds to five minutes, that would be sufficient to get enough root information off of the phone and into a PC editable format.
I ask, because I am in the process of forming a method for the G925V 6.0.1 [PI2] Build. The problem I'm pretty sure I'm going to run into sooner or later in my experiments/research, is the fact that I am one of the few who have the 64GB Verizon S6 Edge. Technically speaking, my device refers to itself in Download/ODIN mode as a SM-G925VZKE model. This also means that my Stock .PIT file is going to be very different than most people's, also meaning my FSTAB configuration probably will be different.
Because there shouldn't be a reason I can't at least get a temporary Root Shell very soon.
So whats up with this? My wife has 6.0.1 on Verizon and I have international much better choice. Will we have root on this phone?
If you are currently on 6.0.1 on your Verizon device. It would serve you well for the time being to disable Automatic Security Updates.
Settings > Lock Screen and Security > Other Security Settings > Security Policy Updates
Turn OFF Automatic Updates, and Turn OFF Wi-Fi Only.
If you leave these on, any potential root option will be patched by Samsung/Google before you know it exists. Disable it for now so you can find an exploit for the build the device is on.
UPDATE:
So apparantly, I've had a rooted 6.0.1 PI2 device persistent through factory resets for over a week, but didn't realize just how much was achieved on my device! According to diagnostics.
I'm already started on writing up the combination of methods that the OP was walking into. Turns out it works up to the September patch too.
But lucky me and not you this time. I got my device essentially decommissioned because I ran my code too soon. But in the sweetest possible way after being so pissed when my tech coach said my warranty was void.
By the end of tomorrow night I should have a thread.
Anyone still working on this?
d0lph said:
Anyone still working on this?
Click to expand...
Click to collapse
Yes. Using the dirtycow vulnerability we've managed to get an arm64 version running that will indeed allow a root console on MM builds.
The last thing standing in the way, for at least a tethered root, is for someone to help me convert the script from the flashable zip version of the SuperSu installer into basically a batch script. Because the how-to guide ChainFire wrote in comments inside his installer script is kind of hard to read because it covers all the different versions of android in a tiny block of text and not every device sets up the same SELinux environment.
Not to mention, if I could get SuperSU to try and install itself as a System Application, it would probably work with what I have already. But for some reason I CANNOT find a single guide anywhere on how to perform a "System" Install of SuperSU, everyone wants to use the "Systemless" version, which is NOT going to work I believe.
We can manage booting the device in the event of DM-Verity Failure, when that happens with the 5.1.1 OG ENG Kernel, we can indeed mount "/system" as read/write, and we can indeed change the contents of the System partition that persist through a reboot.
I just need help setting Perms & Contexts. Because at one point in time, I DID actually manage to get SuperSU to give me a root shell instead of a user shell, but only on the ADB Command Line. In that test I could not get an application to start from the launcher and have Root Permissions.
Delgoth said:
Yes. Using the dirtycow vulnerability we've managed to get an arm64 version running that will indeed allow a root console on MM builds.
The last thing standing in the way, for at least a tethered root, is for someone to help me convert the script from the flashable zip version of the SuperSu installer into basically a batch script. Because the how-to guide ChainFire wrote in comments inside his installer script is kind of hard to read because it covers all the different versions of android in a tiny block of text and not every device sets up the same SELinux environment.
Not to mention, if I could get SuperSU to try and install itself as a System Application, it would probably work with what I have already. But for some reason I CANNOT find a single guide anywhere on how to perform a "System" Install of SuperSU, everyone wants to use the "Systemless" version, which is NOT going to work I believe.
We can manage booting the device in the event of DM-Verity Failure, when that happens with the 5.1.1 OG ENG Kernel, we can indeed mount "/system" as read/write, and we can indeed change the contents of the System partition that persist through a reboot.
I just need help setting Perms & Contexts. Because at one point in time, I DID actually manage to get SuperSU to give me a root shell instead of a user shell, but only on the ADB Command Line. In that test I could not get an application to start from the launcher and have Root Permissions.
Click to expand...
Click to collapse
Thank you for taking the time to still work on this. Subscribed. Following this to the T.
Rand0lph said:
Thank you for taking the time to still work on this. Subscribed. Following this to the T.
Click to expand...
Click to collapse
If you want to follow the complete story of what I just mentioned please follow and contribute to this thread: Injecting Root & Setting SELinux - End Stages?
This is the thread that contains the Greyhat Root console, first designed for the AT&T Galaxy Note 5. But that device uses the same Exynos7420 Mainboard as the Galaxy S6 Edge, so the project is still compatible.
I haven't kept the OP maintained as I should yes. But it is actually worth it to read that whole thread as @droidvoider went out of his way explaining some of his methods. I have a bit of R&D that isn't posted in that thread as well, if you can read up on the project. I'd be more than happy to share what I know with anyone wanting to help as long as they can catch up with what we have accomplished so far.
Look at some of the other threads I've started as well for the initial methods.
Delgoth said:
If you want to follow the complete story of what I just mentioned please follow and contribute to this thread: Injecting Root & Setting SELinux - End Stages?
This is the thread that contains the Greyhat Root console, first designed for the AT&T Galaxy Note 5. But that device uses the same Exynos7420 Mainboard as the Galaxy S6 Edge, so the project is still compatible.
I haven't kept the OP maintained as I should yes. But it is actually worth it to read that whole thread as @droidvoider went out of his way explaining some of his methods. I have a bit of R&D that isn't posted in that thread as well, if you can read up on the project. I'd be more than happy to share what I know with anyone wanting to help as long as they can catch up with what we have accomplished so far.
Look at some of the other threads I've started as well for the initial methods.
Click to expand...
Click to collapse
Sorry, I didn't even acknowledge this is for the EDGE S6. I have a regular Verizon S6.
Rand0lph said:
Sorry, I didn't even acknowledge this is for the EDGE S6. I have a regular Verizon S6.
Click to expand...
Click to collapse
I don't really think that matters as much for the thread I referred to.
I tested the Greyhat Root Console on my S7 Edge, and it worked as well using the September build.
The S6 Line plus the Note 5, all use the same System on a Chip.
If anything, there may be just a couple tweaks to make when compiling it using the NDK.
Given the situation that I needed to unlock bootloader and install TWRP inorder to be able to do full image backup (i.e. Nandroid), I have been wondering what are the underlying security issues to be faced after unlocking and installing TWRP (without moving onto root) in a specific situation where the device is lost or stolen?
Lets say if I am on stock OOS with encryption enabled + Fingerprint and password/pin set on lock screen + USB debugging disabled + locked bootloader + stock recovery, in the unfortunate event where my device were to get lost or stolen, I can expect my personal data to be safe from prying eyes since the person who has gotten a hold of my phone will have to do a factory reset to get into the phone or unlock bootloader which all meant my personal data will be wipe. So that's a good outcome in an unfortunate one.
But let's say if now I were to (i) unlock my bootloader and (ii) install TWRP (but retaining it as read only without system modification), (iii) restore all app, data and settings, and go on to (iv) perform a nandroid backup. And after that, proceed to (v) disable USB debugging and (vi) re-enable encryption and (vii) set fingerprint and password on lock screen. And I shall stopped there without rooting or flashing dm verity. Can I still expect my personal data to be safe from prying eyes in the event of lost or stolen? Meaning that whoever gets a hold of my device will likewise need to wipe it clean before he/she is able to use it? Is this the case or can the person access my data using some hacks now that the device runs custom recovery?
An interesting guide I had came across contained various means of accessing personal data (read - https://forum.xda-developers.com/showthread.php?t=2620456) by bypassing android password, patterns, etc set on the locked screen, and some methods required USB debugging to be enabled while some required custom recovery installed.
To be sure if I am still able to protect my personal data when device is stolen/lost with an unlocked/TWRP installed device, my curiosity took me on an investigative path using an old Samsung Note 3 to unlock bootloader and install TWRP, then proceed to enable encryption and disable USB debugging and set lockscreen password. And now for the next couple of days where I can find free time, I will try out all 7 methods to see if an unlocked Note3 with TWRP is susceptible to these security compromise. I will come back to this thread later to update my findings.
I really welcome any information or inputs too!
To summarize, the state of my old Note 3 used in this investigation is as follows:
1) Bootloader unlocked
2) TWRP (3.0.2) installed as "read only" without system modification
3) ROM (CM13) encryption enabled
4) Locked screen password set
5) Device not rooted
6) USB debugging disabled
When I boot into TWRP, I realized that even if I set it to read only, any person who has gotten hold of my device can set it to system modification since TWRP is not password or pin protected. Therefore setting to "read only" is sort of irrelevant in this investigation to find out how vulnerable the device is right now.
The second thing I realized, is TWRP will ask me for android password to mount my internal sdcard since my ROM is encryption enabled. This is a good thing, since in this case TWRP internal file manager will not be able to access my device internal sdcard containing some of my personal data.
The 1st method I tried is:
METHOD I
Solution For Everyone With Recovery (Cwm, Twrp, Xrec,Etc...) Installed:
INSTRUCTIONS:
1. Download this zip Pattern Password Disable (Download from attachments) on to your sdcard (using your PC, as you cant get into your phone, right )
2. Insert the sdcard into your phone
3. Reboot into recovery mode
4. Flash the zip
5. Reboot
6. Done!
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
The steps I took:
A) Set TWRP to system modification
B) When TWRP asked me for password to mount partition, I choose "cancel" since I am trying to imitate the person who has gotten hold of my device won't be able to guess my password
C) Flashed the pattern password disable zip file
And voila!... my password on locked screen is still intact. Meaning that entering any random password does not gain access into android. Only the original password can.
Good news certainly. Don't know why this hack doesn't work, probably it is outdated or probably due to my system is still encrypted when I flashed the hack zip file.
As to the 2nd method, I didn't try out as I don't know how to use Cygwin...
METHOD 2
Solution For Everyone Without Recovery Installed - ADB :
What You Need:
=>A computer running a Linux distro or Windows+Cygwin
=>USB cable to connect your phone to the PC
=>Adb installed
How to install adb:
1. Open Terminal
2. Type:
Code:
sudo apt-get install android-tools-adb
Hit [Enter]
3. Follow the instructions until everything is installed.
INSTRUCTIONS:
1. Connect you (turned on) Phone to the Computer via USB.
2. Open a terminal window.
3. Type:
Code:
adb devices
adb shell
cd data/system
su
rm *.key
4. Done...Now You Just Have To Reboot.
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
Method 3 is irrelevant to this investigation therefore it has been omitted.
METHOD 3
Solution For Everyone Before Lock Accident :
SMS Bypass - Download Link - Install It On Your Device (Download from attachments)
This App Allows You To Remotely Bypass Your Phone's Screen Lock By Sending A SMS.
It Removes Your Gesture Pattern Or Password After Receiving A Preset Keyword Along With A Secret Code Via SMS.
SMS Bypass App Requires Root.
INSTRUCTIONS:
1.First, make sure you give permanent root access to the app.
2.Change the secret code to your preferred choice. The default password is : 1234
3.To reset your screen lock, send the following message from another phone:
Code:
secret_code reset
Example:
Code:
1234 reset
Note 1 : There is a space between your secret code and reset. Also the secret code is case sensitive.
Note 2 : There is an option available to change the preset keyword. Default is : reset - Your phone will restart and your lock screen will be reset.
Note 3 : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
Given that method 5 is in fact similar to method 2 therefore it has been omitted as well.
METHOD 5
Solution For Everyone Via Adb - File Removal :
INSTRUCTIONS:
=>Type This Command In Your Terminal (CMD Prompt) :
Code:
adb shell rm /data/system/gesture.key
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
Method 6 will not work since that hack required USB debugging to be enabled.
METHOD 6
Solution For Everyone With USB Debugging Enabled :
INSTRUCTIONS:
Primary Step for all method:
Download & Extract to anywhere - Bypass Security Hack (Download from attachments)
Open SQLite Database Browser 2.0.exe in SQLite Database Browser.
Run pull settings.db.cmd inside By-pass security Hacks folder to pull out the setting file out of your phone.
Drag settings.db and drop to SQLite Database Browser 2.0.exe program.
Navigate to Browse data tab, At table there, click to list down the selection & selete secure
Instruction To Remove Pattern Lock:
Now, find lock_pattern_autolock, Delete Record
Close & save database
Run push settings.db.cmd and reboot your phone
Instruction To Remove PIN Lock:
Now, Find Or Create lockscreen.password_type, double-click & change it's value to 65536, Apply changes!
Now, find lock_pattern_autolock, Delete Record, If doesn't exist, Ignore
Close & save database
Run push settings.db.cmd and reboot your phone
Instruction To Remove Password Lock:
Now, find lockscreen.password_salt, Delete Record
Now, find lockscreen.password_type, Delete Record
Close & save database
Run push settings.db.cmd and reboot your phone
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
I then tried out method 7 using the Aroma file manager however all these 3 versions (Version 2.00 [BETA1]- KACAPI, aromafm-1.91, and aromafm-1.90) does not open up after flashing the zip with system modification enabled on TWRP. Mostly likely these outdated versions of the Aroma file manager are not supported by the latest version of TWRP (3.0.2) since the developers have ceased all work related to it.
METHOD 7
Solution For Everyone With Recovery Installed :
INSTRUCTIONS:
1.Download and Copy Aroma File manager.zip (Download from attachments or http://forum.xda-developers.com/show....php?t=1646108) to your memory card.
2. Open your recovery (press volume Down + Power button or it can be different according to the phones. Generally the phones who have press able button on the middle they have to press all three buttons. Google for you pattern there are lots)
3. There’ll b an option in recovery called “mount”. Go in that option and then mount all the cache and everything it is there.
4. Then select “update” and select “apply update from SD/external” and select aroma file manger.zip file that you downloaded using above QR code above.
5. After Flashing or updating, the aroma file manger will open. Use volume keys for up/down and power button 2 select like you use to get into recovery.
6. In aroma File manager , Go to menu , which is located in bottom strip and then select Settings.
7. Go to bottom n select “mount all partition in startup ” then exit from aroma file manger.
8. Now after exit , re-update that aroma file again and it will open again.
9. Go to data >> and then System.
Then find ‘gesture.key’ (for pattern lock) and ’password.key’ (for password lock) then long touch on gesture.key or password.key and sum option will be prompted , choose delete and delete that file and restart.
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
And now onto the last method which is method 4 using SQL command. After starting adb daemon, adb devices are not found and hence the following steps could not be taken. I think this could be due to the device having USB debugging disabled. Hmmm...
METHOD 4
Solution For Everyone Via Adb - SQL Command :
INSTRUCTIONS:
=>Type This Commands Separated In Your Terminal (CMD Prompt) :
Code:
adb shell
cd /data/data/com.android.providers.settings/databases
sqlite3 settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen.lockedoutpermanently';
.quit
=>Now You Just Have To Reboot.
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
After going through all these methods, I am inclined to think that personal data is still protected in an unlocked/TWRP installed device as long as USB debugging is DISABLED and ROM is encrypted and fingerprint/password set on lock screen. What do you think?
As long as your data is encrypted, it is safe and not accessible to any 3rd party.
But with an unlocked bootloader, you are open to a new forms of attacks like:
1. someone could steal your phone, modify your system to leak your data / password and then return it to you. Since dm-verity is OFF, you will not know, that your system is compromised.
2. someone could use a remote exploits (to launch his code and gain root privileges) to modify your system and leak your data / password and since dm-verity is OFF, you will not know, that your system is compromised.
+ with the unlocked bootloader, FRP is not working, so a thief can just reset your phone and sell it.
If your data security is a huge concern to you, DO NOT unlock the bootloader.
If you are a potential target to a hacker attacks, DO NOT use a OnePlus phone. Get a Nexus 6P or a Pixel.
Also make sure, that your apps are not leaking your data. Apps with a storage permission and access to the internet could leak your data.
Michalko5896 said:
As long as your data is encrypted, it is safe and not accessible to any 3rd party.
But with an unlocked bootloader, you are open to a new forms of attacks like:
1. someone could steal your phone, modify your system to leak your data / password and then return it to you. Since dm-verity is OFF, you will not know, that your system is compromised.
Click to expand...
Click to collapse
Many thanks for your response! This is very useful information to me.
Am I right to assume that even if my device is unlocked but with encryption enabled and no root, the person who has gotten hold of my phone will still be able to flash "dm-verity and forced encryption disabler" zip and supersu zip files to root my device in TWRP even when he fails to enter the password prompted by TWRP?
And this force encryption disabler as the name suggest only disable force encryption and it does not decrypt my already encrypted personal data? Which means he still does not have access to my data and after he had done the system modification and returns the phone back to me, the first thing I should do is to wipe clean every partition and restore back my nandroid which would consist of backups to all partitions. So it seems this is an acceptable risk all for the convenience of performing nandroid backup via the unlock/TWRP route.
2. someone could use a remote exploits (to launch his code and gain root privileges) to modify your system and leak your data / password and since dm-verity is OFF, you will not know, that your system is compromised.
+ with the unlocked bootloader, FRP is not working, so a thief can just reset your phone and sell it.
If your data security is a huge concern to you, DO NOT unlock the bootloader.
If you are a potential target to a hacker attacks, DO NOT use a OnePlus phone. Get a Nexus 6P or a Pixel.
Also make sure, that your apps are not leaking your data. Apps with a storage permission and access to the internet could leak your data.
Click to expand...
Click to collapse
Very good point here. May I ask in what ways are Nexus 6P and Pixel more secure than Oneplus? Pixel seemed quite an attractive phone.
I am on OOS 3.5.3, is there anyway to find out what apps have access to internet and restrict that?
The app permission section of settings only allows changing permission to storage (among others) but I couldn't find any internet access permission.
The main security risk is that it allows anyone to flash something harmful without you knowing on to your system. Your data may be encrypted and protected but they can still flash something onto another partition.
You could be happily using your phone unaware there's a rogue app capturing and sending data to someone.
Zegnalabel said:
Many thanks for your response! This is very useful information to me.
Am I right to assume that even if my device is unlocked but with encryption enabled and no root, the person who has gotten hold of my phone will still be able to flash "dm-verity and forced encryption disabler" zip and supersu zip files to root my device in TWRP even when he fails to enter the password prompted by TWRP?
And this force encryption disabler as the name suggest only disable force encryption and it does not decrypt my already encrypted personal data? Which means he still does not have access to my data and after he had done the system modification and returns the phone back to me, the first thing I should do is to wipe clean every partition and restore back my nandroid which would consist of backups to all partitions. So it seems this is an acceptable risk all for the convenience of performing nandroid backup via the unlock/TWRP route.
Very good point here. May I ask in what ways are Nexus 6P and Pixel more secure than Oneplus? Pixel seemed quite an attractive phone.
I am on OOS 3.5.3, is there anyway to find out what apps have access to internet and restrict that?
The app permission section of settings only allows changing permission to storage (among others) but I couldn't find any internet access permission.
Click to expand...
Click to collapse
Your data is safe, it can't be decrypted, even with an unlocked bootloader And yes, if you wipe every partition, lock the bootloader and got no dm-verity error, after your stolen phone was returned to you, you should be safe.
Both Nexus 6P and Pixel are much safer than OnePlus, because they are getting a complete security patches every month. OnePlus is getting an imcomplete security patches and much later after their release.
You can limit access to internet via app settings. Open "about app", data usage and there you can turn off both access to wifi and mobile data.
Upgrade to OOS 4.0, it cointains important security patches and enhancements.
Michalko5896 said:
Your data is safe, it can't be decrypted, even with an unlocked bootloader And yes, if you wipe every partition, lock the bootloader and got no dm-verity error, after your stolen phone was returned to you, you should be safe.
Both Nexus 6P and Pixel are much safer than OnePlus, because they are getting a complete security patches every month. OnePlus is getting an imcomplete security patches and much later after their release.
You can limit access to internet via app settings. Open "about app", data usage and there you can turn off both access to wifi and mobile data.
Upgrade to OOS 4.0, it cointains important security patches and enhancements.
Click to expand...
Click to collapse
Thank you so much! Found the data usage setting and updated to 4.0. :laugh:
Michalko5896 said:
As long as your data is encrypted, it is safe and not accessible to any 3rd party.
But with an unlocked bootloader, you are open to a new forms of attacks like:
1. someone could steal your phone, modify your system to leak your data / password and then return it to you. Since dm-verity is OFF, you will not know, that your system is compromised.
2. someone could use a remote exploits (to launch his code and gain root privileges) to modify your system and leak your data / password and since dm-verity is OFF, you will not know, that your system is compromised.
...
Click to expand...
Click to collapse
Quick question, does the latest systemless SuperSU still leave dm-verity OFF ? It was my understanding that using it you don't need to flash the dm-verity-OFF script, is that true?
xclub_101 said:
Quick question, does the latest systemless SuperSU still leave dm-verity OFF ? It was my understanding that using it you don't need to flash the dm-verity-OFF script, is that true?
Click to expand...
Click to collapse
For root, you need to unlock the bootloader. And with the bootloader unlocked, dm-verity is not working and thus attacker could modify your system.
Michalko5896 said:
For root, you need to unlock the bootloader. And with the bootloader unlocked, dm-verity is not working and thus attacker could modify your system.
Click to expand...
Click to collapse
The bootloader being locked/unlocked should have little to do (directly) with dm-verity, dm-verity is only hash-checking the system partition.
That being said after some checking various detailed threads from Chainfire apparently SuperSU is still removing the dm-verity on the system partition since other than rooting in itself most rooted people also tend to touch the system partition with stuff like busybox and so on, so I guess this is it.
xclub_101 said:
The bootloader being locked/unlocked should have little to do (directly) with dm-verity, dm-verity is only hash-checking the system partition.
That being said after some checking various detailed threads from Chainfire apparently SuperSU is still removing the dm-verity on the system partition since other than rooting in itself most rooted people also tend to touch the system partition with stuff like busybox and so on, so I guess this is it.
Click to expand...
Click to collapse
well, google is stating, that unlocking bootloader will turn off the dm-verity.
This is an interesting discussion- I have a Nexus 5X, but I use a custom configuration:
1) locked bootloader
2) verity turned on for the system partition so that I can check the key fingerprint and verify integrity.
3) customized cm recovery - I installed my adb keys so I can connect to it. I also changed the signing keys, so I have to sign any roms that get flashed.
4) encrypted userdata with pattern protection. I think a password would be stronger, but I'm using a larger, complex pattern. Fingerprint unlock is turned on, which has its own attack surface.
I think the fingerprint sensor is the biggest risk. This is mitigated at reboot since the pattern will be required. If I built the recovery properly, the only way to flash anything would be to have access to my signing keys or adb keys. Of course, this is all still vulnerable to any unpatched exploits.
TWRP 3.0.2 and systemless supersu 2.79
You must unlock bootloader first
From bootloader menu
*- To permanently install
fastboot flash recovery (TWRP files name)
*- Running TWRP without installing
Fastboot boot (twrp files name)
download
TWRP 3.0.2 android M
TWRP 3.0.2 Android N (Android wear 2.0)
systemless Wear SU 2.79 from
https://forum.xda-developers.com/apps/supersu/android-wear-6-0-1-root-squashfs-t3319097
To CHANGE (ADDING or EDITING) APN
edit or add apn on two files (APN-Name and value MUST MATCH between these two files)
The watch select and display APN selection based on MCC and MNC value that stored under the SIM card
(you can see the sim card value under telephony.db under siminfo data)
*- apns-conf.xml
/system/etc/apns-conf.xml
*- telephony.db
/data/data/com.android.providers.telephony/databases/telephony.db
You can push and pull these files from recovery menu main screen
1- Boot into TWRP
2- Mount System as RW (from mount menu)
3- connect the watch into computer and install ADB drivers.
4- Than run adb pull to get the files
Edit the files (by adding APN or edit existing carriers APN)
apns-conf.xml with any text or xml editor
telephony.db (under data and carriers) with Db browser for sqllite or any sql editor
APN name and data value on both files MUST BE THE SAME/MATCH otherwise the watch wont load the selection
5- ADB push to push the files back to the watch
6. Run shell command to change permission, ownership and group
apns-conf.xml - chmod 644 (rw r r), chown and chgrp root
telephony.db - chmod 660, chown and chgrp radio
Wanting to try this, but it isn't letting me mount /system. TWRP log says "Failed to mount '/system' (No such device)". The "Mount system RO" checkbox checks, but doesn't actually mount RO either.
I also looked for the telephony.db and it didn't exist at /data/data/com.android.providers.telephony/databases/telephony.db. The "databases" folder doesn't exist. Couldn't check for the one in /system
Running wear 2.0, so I DL'd the correct TWRP. I did boot-only, not flash.
Any ideas?
Concur.
Rayfen Windspear said:
Wanting to try this, but it isn't letting me mount /system. TWRP log says "Failed to mount '/system' (No such device)". The "Mount system RO" checkbox checks, but doesn't actually mount RO either.
I also looked for the telephony.db and it didn't exist at /data/data/com.android.providers.telephony/databases/telephony.db. The "databases" folder doesn't exist. Couldn't check for the one in /system
Running wear 2.0, so I DL'd the correct TWRP. I did boot-only, not flash.
Any ideas?
Click to expand...
Click to collapse
I have the same problem with TWRP and System RO. I did it in the same manner for booting from bootloader, because the flashing of recovery does not work correctly. I flash the TWRP using fastboot flash recovery, but every time I attempt to boot into recovery I get the same android icon with a red triangle over the top and an exclamation inside. I did not check the apn, because if I cannot go into recovery or flash SU I know that would be useless to even try. Same here device name nemo from bootloader screen using wear 2.0 (Android 7.1.1). Unlocked using fastboot oem unlock.
My Nexus 5 is rooted with custom Nougat ROM and it does NOT have the .db in the data directory. Given that they use a lot of the same AOSP code, it's probably safe to say that Wear 2.0 (nougat 7.1.1) doesn't need this here either. My conclusion then, is that they have consolidated these settings to the XML in the /system directory, which we cannot mount.
In the thread linked for the systemless su, it mentions that system is read only as it is squashfs. I can only assume that this applies to /system/etc/apns-conf.xml, so I'm not sure how OP was able to push the modified file back to /system in the first place without taking this into account.
Got it working with my FreedomPop SIM. Should work to add any APN. So I combined this with another guy's guide. There are two main differences.
First off, use twrp-3.1.1.0.img from this guy's thread. https://forum.xda-developers.com/lg-urbane-2/how-to/root-twrp-squashfs-3-1-1-lg-urbane-2nd-t3661569
Then it works to mount /system as READ ONLY, which allows you to use the systemless-su from this thread. WARNING: This may not modify the system, but it does modify and reflash another partition (I didn't catch which). I do not know if this will prevent your device from receiving OTAs afterward (It updates, see edit below). ALSO, because there isn't a SuperSU app, there is no management of what can use su privileges. Any app could discover root and do whatever without your knowledge. I plan to remove su from my watch when I get around to it now that my APN has been added. I will post how when I do.
EDIT: I just received an update through the Play Store that updated my AW version, build number, the works. Security patch August 1st. The APN I added persists after the update, though it showed the "no sim" icon until I went and manually enabled cell and selected the APN again.
After getting that done, follow these instructions for adding the APN starting from the header "Add the APN via the ADB shell". https://michaeltroger.github.io/blog/2017/08/12/add-apn-in-android-wear-2
Adding FreedomPop's data APN went as follows:
adb shell
su
content insert --uri content://telephony/carriers --bind name:s:"FreedomPop" --bind numeric:s:"310170" --bind type:s:"default,supl" --bind mcc:i:310 --bind mnc:i:170 --bind apn:s:"fp.com.attz"
If you happen to mess up, or have to add it with trial and error as I did, you can use the following two commands to fix things.
content query
content delete
Using the where clause as exampled in the above link.
NOTE: I just found out that as these changes are systemless, they DO NOT survive an unpair/reset.
Use this TWRP instead for Android wear 2
I modified from Android wear 2 stock recovery
TWRP 3.1.1
https://drive.google.com/open?id=0B4W0KuzRjVvGNkF1UnFkQkFBcU0
Systemless root
https://drive.google.com/open?id=0B4W0KuzRjVvGMzJka1dGRFM2dGc
Dont flash TWRP instead run fastboot boot (TWRP image name)
You wont be able to flash any OTA update with TWRP.
Your watch will keep rebooting to TWRP if you try to download and install any OTA.
Rayfen Windspear said:
Got it working with my FreedomPop SIM. Should work to add any APN. So I combined this with another guy's guide. There are two main differences.
First off, use twrp-3.1.1.0.img from this guy's thread. https://forum.xda-developers.com/lg-urbane-2/how-to/root-twrp-squashfs-3-1-1-lg-urbane-2nd-t3661569
Then it works to mount /system as READ ONLY, which allows you to use the systemless-su from this thread. WARNING: This may not modify the system, but it does modify and reflash another partition (I didn't catch which). I do not know if this will prevent your device from receiving OTAs afterward (It updates, see edit below). ALSO, because there isn't a SuperSU app, there is no management of what can use su privileges. Any app could discover root and do whatever without your knowledge. I plan to remove su from my watch when I get around to it now that my APN has been added. I will post how when I do.
EDIT: I just received an update through the Play Store that updated my AW version, build number, the works. Security patch August 1st. The APN I added persists after the update, though it showed the "no sim" icon until I went and manually enabled cell and selected the APN again.
After getting that done, follow these instructions for adding the APN starting from the header "Add the APN via the ADB shell". https://michaeltroger.github.io/blog/2017/08/12/add-apn-in-android-wear-2
Adding FreedomPop's data APN went as follows:
adb shell
su
content insert --uri content://telephony/carriers --bind name:s:"FreedomPop" --bind numeric:s:"310170" --bind type:s:"default,supl" --bind mcc:i:310 --bind mnc:i:170 --bind apn:s:"fp.com.attz"
If you happen to mess up, or have to add it with trial and error as I did, you can use the following two commands to fix things.
content query
content delete
Using the where clause as exampled in the above link.
NOTE: I just found out that as these changes are systemless, they DO NOT survive an unpair/reset.
Click to expand...
Click to collapse
Is Safetynet working after removing root? I presume you can still sideload updates or that there is a method to return to stock if SafetyNet is tripped?
sjavvaji said:
Is Safetynet working after removing root?
Click to expand...
Click to collapse
I never got around to forcefully disabling/removing it. Nor have I gotten around to redoing it after unpaid/reset wiped it all. How would I test that? I'll get it back on and working then remove root this time sometime this week and give it a go. I don't use Android pay, so I'm not sure how I would test it. Perhaps I could adb push one of the checker apps for phone and hope it works?
Rayfen Windspear said:
I never got around to forcefully disabling/removing it. Nor have I gotten around to redoing it after unpaid/reset wiped it all. How would I test that? I'll get it back on and working then remove root this time sometime this week and give it a go. I don't use Android pay, so I'm not sure how I would test it. Perhaps I could adb push one of the checker apps for phone and hope it works?
Click to expand...
Click to collapse
That would be one way to do it. I have my watch coming in tomorrow and a Freedompop sim on the way. I would prefer Android Pay working over data but having both working is optimal.
sjavvaji said:
That would be one way to do it. I have my watch coming in tomorrow and a Freedompop sim on the way. I would prefer Android Pay working over data but having both working is optimal.
Click to expand...
Click to collapse
Just getting around to tinkering today. Did a bit of research and found that installing the systemless SU modifies the kernel. I'm going to dig a little deeper and hopefully come up with a zip to flash that will completely undo everything that is done by the SU zip (if there isn't one already) to make sure that safetynet not only passes, but that the kernel is stock and secure too. The recent update they pushed for Aug security patch possibly updated the kernel too, yet the APN survived, so once set, APNs definitely live in the userdata and should be fine.
Rayfen Windspear said:
Just getting around to tinkering today. Did a bit of research and found that installing the systemless SU modifies the kernel. I'm going to dig a little deeper and hopefully come up with a zip to flash that will completely undo everything that is done by the SU zip (if there isn't one already) to make sure that safetynet not only passes, but that the kernel is stock and secure too. The recent update they pushed for Aug security patch possibly updated the kernel too, yet the APN survived, so once set, APNs definitely live in the userdata and should be fine.
Click to expand...
Click to collapse
Let me know how it goes! I would honestly just like to get the APN working and return to stock. So assuming it works, the process would go, unlock bootloader, run TWRP w/o install, install systemless SU, edit APN, run TWRP w/o install, uninstall systemless SU, and bootloader relock. Am I missing anything?
sjavvaji said:
Let me know how it goes! I would honestly just like to get the APN working and return to stock. So assuming it works, the process would go, unlock bootloader, run TWRP w/o install, install systemless SU, edit APN, run TWRP w/o install, uninstall systemless SU, and bootloader relock. Am I missing anything?
Click to expand...
Click to collapse
Ooooh... does SafetyNet check for an unlocked bootloader? Does relocking it force a data wipe? I can't remember, because once I unlock, I've never gone back
Rayfen Windspear said:
Ooooh... does SafetyNet check for an unlocked bootloader? Does relocking it force a data wipe? I can't remember, because once I unlock, I've never gone back
Click to expand...
Click to collapse
Yeah. I forgot it required a data wipe. That might be an issue lol.
So is there a way to install Magisk? Or any way to bypass the SafetyNet check and a way to reverse the systemless SU check?
Edit:
I did some more research and it seems like we might be able to install Magisk in place if the systemless root uses SuperSU. Other LG watches in the past and android wear devices in general have been rooted using Magisk in place of SuperSU and it seems to pass safetynet.
hoodred said:
TWRP 3.0.2 and systemless supersu 2.79
You must unlock bootloader first
From bootloader menu
*- To permanently install
fastboot flash recovery (TWRP files name)
*- Running TWRP without installing
Fastboot boot (twrp files name)
download
TWRP 3.0.2 android M
TWRP 3.0.2 Android N (Android wear 2.0)
systemless Wear SU 2.79 from
https://forum.xda-developers.com/apps/supersu/android-wear-6-0-1-root-squashfs-t3319097
To CHANGE (ADDING or EDITING) APN
edit or add apn on two files (APN-Name and value MUST MATCH between these two files)
The watch select and display APN selection based on MCC and MNC value that stored under the SIM card
(you can see the sim card value under telephony.db under siminfo data)
*- apns-conf.xml
/system/etc/apns-conf.xml
*- telephony.db
/data/data/com.android.providers.telephony/databases/telephony.db
You can push and pull these files from recovery menu main screen
1- Boot into TWRP
2- Mount System as RW (from mount menu)
3- connect the watch into computer and install ADB drivers.
4- Than run adb pull to get the files
Edit the files (by adding APN or edit existing carriers APN)
apns-conf.xml with any text or xml editor
telephony.db (under data and carriers) with Db browser for sqllite or any sql editor
APN name and data value on both files MUST BE THE SAME/MATCH otherwise the watch wont load the selection
5- ADB push to push the files back to the watch
6. Run shell command to change permission, ownership and group
apns-conf.xml - chmod 644 (rw r r), chown and chgrp root
telephony.db - chmod 660, chown and chgrp radio
Click to expand...
Click to collapse
Is there a way to flash back to stock AW 1.5?
Sent from my SM-G965U using Tapatalk
Could someone please point me at instructions on how to root LN14.
I've searched the HD/HD+ forums for 'root LN14' and 'rooting LN14' and got no results (which by itself is suspicious).
have you enabled Developer Options?
I, for one, had no luck with either SuperSu or addon su. The first would put the HD+ into a permanent boot loop necessitating a re-install from scratch,and the latter would install but the unit still indicated it was not rooted. Doing the Dev Op made no difference. A real mystery!
harryzee said:
I, for one, had no luck with either SuperSu or addon su. The first would put the HD+ into a permanent boot loop necessitating a re-install from scratch,and the latter would install but the unit still indicated it was not rooted. Doing the Dev Op made no difference. A real mystery!
Click to expand...
Click to collapse
The file addonsu-14.1-arm.zip in the main folder is the one to use. As I seem to recall, you might have to enable, disable, then re-enable, in order for root access to take effect.
digixmax said:
The file addonsu-14.1-arm.zip in the main folder is the one to use. As I seem to recall, you might have to enable, disable, then re-enable, in order for root access to take effect.
Click to expand...
Click to collapse
That is the one I flashed using 3.0.1.0 TWRP. Not clear on your second sentence: "...enable, disable,, then re-enable...". Forgive me for being lost as to what you physically/specifically mean. Please explain.
Thanks.
harryzee said:
That is the one I flashed using 3.0.1.0 TWRP. Not clear on your second sentence: "...enable, disable,, then re-enable...". Forgive me for being lost as to what you physically/specifically mean. Please explain.
Thanks.
Click to expand...
Click to collapse
I meant "enable, disable,, then re-enable" the root access option in "Developer Options".
Aha! Will give it a go. Thanks.
5/2/2018:
Okay: I d/l three android root checkers and titanium backup. The first root checker (Clivin Inc. with small green android robot graphic) told me I was not rooted both before following your above instructions and after. The other two (d/l after following the above) both say I am rooted. However, I was not and am still not able to get "TB" to run. It says "failed" and that I am not rooted.
Since the HD+ is running really well now in its stripped down mode, I can "leave well enough alone" or try to get "TB" working so I can remove anything not needed for my chosen minimal functionality (ereader, viewing videos, photo review/minor editing) that would further reduce unnecessary battery drain.
Thanks again for the above clarification and any additional thoughts.
I am having this same problem
- Root options *do* appear in my Developer settings, but no amount of toggling on/off/on seems to enable root
- I have flashed the Lineage SU addon, log shows successful in TWRP but no change after boot
- SuperSU from Play Store says "SU Binary occupied"
- Adaway says "Rooted Android required- Either the su binary could not be found or you did not allow root permission for Adaway" ie I believe I am indeed *not* rooted.
- SuperSU flashable zip is a broken link on their website.... http://www.supersu.com/download
Out of ideas here, anyone got anything else I can try?
Edit: I was able to obtain Root properly by flashing Magisk & installing the Magisk Manager APK from here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
You got it. Use Magisk. Works wonders and way better than SuperSU or any other root permission tool I've came across. It's even akin to, and even has within it, xposed and other magical rooted modules for you to try out for a day or two and then decide you don't need it.
pchc_lx said:
I am having this same problem
- Root options *do* appear in my Developer settings, but no amount of toggling on/off/on seems to enable root
- I have flashed the Lineage SU addon, log shows successful in TWRP but no change after boot
- SuperSU from Play Store says "SU Binary occupied"
- Adaway says "Rooted Android required- Either the su binary could not be found or you did not allow root permission for Adaway" ie I believe I am indeed *not* rooted.
- SuperSU flashable zip is a broken link on their website.... http://www.supersu.com/download
Out of ideas here, anyone got anything else I can try?
Edit: I was able to obtain Root properly by flashing Magisk & installing the Magisk Manager APK from here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
Click to expand...
Click to collapse