Did I found a Security Hole? - Galaxy Note 4 General

I take too serious the security in my device. I'm not a computer technician or anything, just a normal-to-advanced user who tends to change things in my device more frequently than my pants. This happend accidentally while trying to replace my SystemUI.apk with a modified one. My phone uses a pattern to unlock it at system level (lockscreen protection, not SIM). So I changed the SystemUI, I've set permissions and rebooted. For some reason the apk didn't worked, resulting in a constant "Android is Upgrading" window. I pressed the power button to lock it, and the screen went off. I pressed it again and my device booted directly to my homescreen with a message saying that my System UI has stopped working. But wait: No pattern unlock? I connected my device via USB to my PC and I was able to see all my files inside (normally, if your device is locked with pattern/pin/finger/etc and connect it to a PC it will not show any file in sdcard0, just an empty folder). The phone was almost unusable because if I press OK in the FC popup a new one would appear 0.5sec later, but I was able to open multiple apps and even type with the keyboard to a Whatsapp contact (with a little of patience) within one popup and another. I even replaced my corrupted SystemUI with root explorer...
So the question is: Is this a security hole? For now this could happen only to Rooted users since there's no way to modify a System apk without root privileges. But if someone manages to break the SystemUI without needing to root the device, he would have access to anything inside your device...
Here's my device info:
Samsung Galaxy Note 4 N910C
Android Version 5.0.1
Build: N910CXXU1BOC5
Deodexed
If anyone experience in security read this, please give me an opinion. Thanks!

It's not a security hole, the keyguard doesn't really do much in the way of security. Device encryption is another matter entirely - that's sure to protect your device if the attacker doesn't know the passcode.
Rooting sidesteps many of the security measures put into place by the OS, and that's why rooting trips the Knox counter.

galaxynote2 said:
I take too serious the security in my device. I'm not a computer technician or anything, just a normal-to-advanced user who tends to change things in my device more frequently than my pants. This happend accidentally while trying to replace my SystemUI.apk with a modified one. My phone uses a pattern to unlock it at system level (lockscreen protection, not SIM). So I changed the SystemUI, I've set permissions and rebooted. For some reason the apk didn't worked, resulting in a constant "Android is Upgrading" window. I pressed the power button to lock it, and the screen went off. I pressed it again and my device booted directly to my homescreen with a message saying that my System UI has stopped working. But wait: No pattern unlock? I connected my device via USB to my PC and I was able to see all my files inside (normally, if your device is locked with pattern/pin/finger/etc and connect it to a PC it will not show any file in sdcard0, just an empty folder). The phone was almost unusable because if I press OK in the FC popup a new one would appear 0.5sec later, but I was able to open multiple apps and even type with the keyboard to a Whatsapp contact (with a little of patience) within one popup and another. I even replaced my corrupted SystemUI with root explorer...
So the question is: Is this a security hole? For now this could happen only to Rooted users since there's no way to modify a System apk without root privileges. But if someone manages to break the SystemUI without needing to root the device, he would have access to anything inside your device...
Here's my device info:
Samsung Galaxy Note 4 N910C
Android Version 5.0.1
Build: N910CXXU1BOC5
Deodexed
If anyone experience in security read this, please give me an opinion. Thanks!
Click to expand...
Click to collapse
So you gave the user root access and you say you are concerned about security? :silly: A silly screen unlock pattern is not going to save you, as anyone with a a computer can access everything on your phone and make any changes they want (granted they have access to you phone).

Security hole can be said of you are uprooted. You changed (corrupted) systemui means you have rooted device and since screen guard is part of systemui so how can you expect to work normally.
Also not difficult to reproduce. Simply delete systemui with root explorer, your device will reboot normally without pattern though you have set it. Even you can explore all files with root explorer (that means you can do almost anything) and can change pattern lock with setting too. Just you will have black wallpaper and no status bar. Once you replace systemui you will have your pattern lock back.
In sort you are rooted users your are no more secured.
Even not rooted but simply having custom recovery you are not secured. Any script having command to delete your pattern /pw it can be deleted from that even device is not rooted as custom recovery can mount partition and can edit it.
That's why Samsung trip knox even by flashing custom recovery.
Sent from my SM-N910G using xda premium

Related

[GUIDE] Dirty flash from lpv to LRX21O

So like many of you who were running the awesome LPV build for the past few months and just recently tried updating to official Lollipop (LRX21O) have likely run into issues on first boot (black screen with only a back button). In this state/issue the phone will respond to "OK Google" but nothing else. The pulldown shade will also be present but show nothing. The issue appears to be related to the lock screen. The following is how I fixed my issue, and I will be looking at this thread to try and update the OP as we pin down the EXACT issue, but I believe I have a fix:
NOTE: If you've already updated and are AT the black screen, I hope you have a backup to restore as you'll need to revert to change some settings. If not, you may find flashing the system.img or zip of your old build (LPV) allows you access to your phone again to access these settings.
1. Restore backup or revert if necessary so you can access settings BEFORE flashing LRX21O.
2. Settings-Security-Screen Lock Make sure you have one set other than swipe so you can perform the next step (we will change this back later)
3. Go to "Trust Agents" on the same screen (Security) and turn OFF SmartLock
4. Go back to screen lock, now select SWIPE (or none if present, but I don't believe it's an option on most)
5. (Optional) I chose to both enable USB debugging as well as going into SuperSU (if present) and setting it to grant all requests. I did not need this, however if you're having issues it may help your troubleshooting to have root adb access.
6. With your lock screen set to swipe and smart lock off, now try flashing LRX21O, followed by a custom kernel (or boot.img if you have it) and/or root in that order if you'd like.
7. Upon boot, it SHOULD have resolved the black-screen issue. I did still have the "non-working home button" issue that was quickly resolved by running the setup wizard again with the following command via adb:
adb shell am start -n com.google.android.setupwizard/.SetupWizardTestActivity
When it asks about restoring backups or setting up as a new device, choose set up as new device. The "Restore" would simply re-download and restore apps that are already installed. "Set up as new device" simply tells setup to do nothing, which is fine, because all your data is already there
8. SDcard Fix (root required): If you have issues seeing SD card content, use these ADB commands below (credit to rootSU here
su
restorecon -FR /data/media/0
That's IT! You should be set. I love dirty flashing (I know everyone hates it because yes, it does cause a lot more chatter in the forums, but that's half the fun ) and problem solving. Everytime I see someone claiming they fixed a problem by factory resetting I'm thinking "...that's like saying you fixed your car by buying a new car". I hope I this makes other's lives a little easier

[Q] Locked out of phone - No keyboard at "To start Android, enter your pin"

I'm rooted on 6.0.1 with xposed and twrp.
I've always used a pattern to lock my phone, and I've checked the box "require pattern to start device".
Last night I decided to switch to a pin vs a pattern for some reason.
I installed a new xposed module today (xposed gel settings for those curious).
When I restarted my device it prompted me to enter my pin. A cursor is displayed in the entry field, however, no keyboard is displayed.
You can hold down the cursor in the field and it vibrates, but does nothing.
I tried wiping the cache, restarting in safe mode, using android device manager.
You can select "Emergency Call" at bottom of screen and the dialer pops up.
Does anyone know what's causing this?
I'm not sure if it's one of my xposed modules causing the problem.
The only thing I can even think of that may be causing it is:
When I flashed twrp, I opted to keep my system read only.
For some reason that leads me to believe that the system folder (where I'm assuming google keyboard is located) isn't mounted at start-up and therefor the keyboard app isn't running yet. However since you can open the dialer to make an emergency call, I'm guessing this isn't a correct guess.
Any assistance would be wonderful. Thank you!
EDIT: Super late edit, but an OTG cable and keyboard fixed the issue. I can't remember if I figured out what the issue was.
No idea what's causing that. If you have an OTG cable about you could try connecting a usb keyboard to enter pin?
just so that you know, exposed cause many undocumented issues. issues that have no explanation are generally caused by exposed, if you have it installed. I recommend getting rid of closed and reflaahing your ROM.
and, setting up as read only could cause this issue as well. why would you do read only in your recovery? lol. you use the recovery to change things, read only can't change anything.
simms22 said:
just so that you know, exposed cause many undocumented issues. issues that have no explanation are generally caused by exposed, if you have it installed. I recommend getting rid of closed and reflaahing your ROM.
and, setting up as read only could cause this issue as well. why would you do read only in your recovery? lol. you use the recovery to change things, read only can't change anything.
Click to expand...
Click to collapse
I did it initially to make a nandroid backup of my phone with plans of changing it. I was never prompted to make it read/write and can't find it in settings.
neil_swann80 said:
No idea what's causing that. If you have an OTG cable about you could try connecting a usb keyboard to enter pin?
Click to expand...
Click to collapse
I plan on trying this once I get home. Hopefully it works. I'm not sure at what point in the boot process an external keyboard is considered an input method.
nioletmc said:
I did it initially to make a nandroid backup of my phone with plans of changing it. I was never prompted to make it read/write and can't find it in settings.
Click to expand...
Click to collapse
to make a nandroid backup, you need to change something(write to storage), so read only wouldn't be able to make a backup.
Had the same issue as OP, new Nexus 6 user and have always used pin but I've changed to pattern because of this, only way to start was to use an OTG adapter and a USB Keyboard to input pin, haven't had issues with pattern unlock with xposed or otherwise.
Try to flash a keyboard. Hopefully IME switcher is shown at this stage.
Try to find a keyboard apk and use the zip posted here:
http://forum.xda-developers.com/crossdevice-dev/sony/flashable-appsflash-apps-internal-t2809020
Maybe try disabling xposed. There are two different ways to disable xposed:
1. there is a way to disable Xposed during powerup by repeatedly pressing the a hardware key.. SEE here
http://forum.xda-developers.com/xpo...-modifying-t1574401/post51306764#post51306764
Code:
Quick explanation of the safemode: It was developed by [user=4322181]@Tungstwenty[/user] and makes it possible to disable Xposed by repeatedly pressing one of the hardware buttons during early startup. The phone will vibrate twice when the first key press has been detected. Then you have five seconds to press the same button four more times. Each key press will be confirmed with a short vibration; the final one with a long vibration. It creates /data/data/de.robv.android.xposed.installer/conf/disabled, which prevents most of Xposed's actions (e.g. no hooks are made and no modules are loaded). There's no 100% guarantee that this will get you out of a bootloop, but in most cases it should.
2. you can flash an xposed disabler zip file available in the xda xposed thread
http://forum.xda-developers.com/xposed/xposed-installer-versions-changelog-t2714053
Code:
If that doesn't work, you can flash the attached Xposed-Disabler-Recovery.zip by Tungstwenty. It will be copied to your (external) SD card when you install Xposed as well. The only thing it does is copying /system/bin/app_process.orig back to /system/bin/app_process, which you can also do yourself (e.g. with adb shell in recovery mode).
So, how did your adventure end? I hate to see a loose thread...

[ROOT] SM-T707A - Lollipop with SuperSu - Xposed & Debloated - Part II

Root SM-T707A on Lollipop with SuperSu - Xposed & Debloated - Part II
Where are we right now?
* Part I: Flash Stock Lollipop 5.0.2.
* Part II: Gain Root access for Lollipop with SuperSU. <---- YOU ARE HERE!
* Part III: Flash Xposed Framework thru Flashfire.
* Part IV: Debloat the tablet from both AT&T and most of Samsung stuff.
* Part V: Improve usability and aspect with Xposed Modules.
Once again, some words of our sponsors: NO, I'm NOT resposible for any consequence originated from the use of this guide, being that the death of your tablet, or your smart tv, the Panama Papers or Luis Suarez just playing rough with Filipe Luiz's foot. Whatever happens to your tablet, it's ON YOU.
Introduction (PLEASE READ!):
This guide works as a continuation of Part I, so we assume you flashed KitKat and applied Lollipop updates as described.
If you are already on Lollipop and have several weeks using it, of course you can try this guide, but I STRONGLY SUGGEST to start from zero, backup your files and use the guidelines on Part I of this guide.
Part II: Gain Root access for Lollipop with SuperSU
IMPORTANT - During the first boot on our brand new lollipop, don't try to connect to your WiFi and remove your SimCard if availble before even selecting any option. We don't want any internet at this time.
Our first move in Lollipop is to Reject all the AT&T offers..
Then accept terms of Samsung EULA (and hit No Thanks below)...unless you want to share information with Sammy.
Then you can put your name (I didn't), it' s up to you.
Disable the 3 checkboxes for location services (you can enable this later).
Then skip the Samsung Account creation and hit also Next on my "Find my mobile" screen without doing nothing.
Finally, you'll reach the Android Desktop.
Setting the stage for rooting with KingRoot
Still avoiding any conection to the internet, go to your apps and tap Settings.
Before doing nothin, I strongly suggest you change your language to english in case you use another.
If your first language is English, you're good.
If it's not, you can change it on General TAB, then "Language and Input".
After this, tap the Device tab, choosing then Display option on the left.
Choose Screen timeout and select 10 minutes.
Now select Lock screen on your left and Screen lock on your right. Tap "None".
Now go to "General" tab and tap "Security".
Enable the Unknown sources checkbox and press OK on the popup.
Press home button. Now you can connect to your Wifi.
The moment you got Internet, Samsung will start forcing some updates on your tablet.
At the same time, several Google popups will ask you to "regularly check device for security".
Decline them all the time!
There is a "Games" app that loves to open itself without asking
When that happens, it will introduce you to an agreement that you will REJECT.
If it doesn't show, better. But it will eventually.
Now enter the Play Store and Log in with your credentials.
Accept the playstore conditions when prompted. If you are kicked out of the app just enter again.
Still inside Playstore, now swipe from your left side border to gain access to the menu.
Tap "My Apps" and use the "Update All" button on the right.
Accept all APP Permisions (seven times in my case).
The update process will start. This will take some time so BE PATIENT and do nothing else.
When everything is updated, you'll notice some warning on your status bar.
Swipe down your status bar. It will ask several times to Update Google Play Services.
Tap any of update offers for Play Services. Playstore will open again offering the update.
Hit Update and Accept. When the update of Google Play Services is finished, hit the Open button.
You gain access to Google Settings. Tap Security.
Disable "Remote locate this device" - "Allow remote lock and erase".
Disable also "Scan device for security threats" and "Improve harmfull app detection" (unless is greyed out).
Hit the home button and go back to desktop.
Installing KingRoot
For the next step, you need to download these files on your PC:
* Kingroot V4.90
* RemoveKing
Copy them on your tablet's internal memory. Specifically on the root of your internal memory. If you copy them inside a folder, later commands will fail.
Back to your tablet's desktop, look for the folder icon on the bottom left corner. This will open the Samsung File Manager. Look for "Device Storage" on the left column. If you copied the files correctly, you'll find both on the right pane of the display. Extract the RemoveKing.zip file by tapping it and clicking "OK". A RemoveKing folder will appear on the root of your filesystem.
Now open the Kingroot V4.90 file. Hit Next and then Install.
If a google warning appears citing - "Installation blocked". Hit "Install anyway" (unsafe).
If it doesnt, just hit Open. A blue screen shows up with the legend "ROOT auth".
Swipe upwards twice (assuming you're holding your tablet in portrait).
Now hit the "Try it" button. The app will verify root status in a matter of seconds.
Now tap the "TRY THE ROOT" button at the bottom.
When the root is sucessful, you'll be asked to "Forbid Knox".
Tap Cancel and press the home button. Now you are rooted with Kingroot.
Installing and preparing Terminal Emulator
Now that we are rooted, enter the playstore and install the app "Terminal Emulator for Android". Open it. You'll notice some small font selected so, hit the 3 dots on the right upper corner and go to preferences. On Font Size choose 24 pt. Hit the back physical button of the tablet. Now the "white letters" become readable. And it shows something like:
Code:
klimtlteatt:/ $
Next type the following and hit enter:
Code:
su
A Kingroot popup will ask for root permission. Tap "Allow".
Now the $ symbol will change for #.
Next you hit the HOME button to exit the app briefly (don't close the app in any other way, just hit the HOME button).
Uninstalling KingRoot
After that, go to your apps and enter the KingRoot app.
Now tap the 3 dots on the upper right corner and select "General Setting". Disable "Smart Authorization", then disable "Enable Root Authorization". Finally choose below "Uninstall KingRoot". Hit Continue. Uncheck "Backup Root" when prompted and hit OK. When all is over, you're back to the desktop. Go back again to your apps and uninstall Purify.
Applying the Scripts
Open again Terminal Emulator app (thru the app Icon) . Now we need to hit a couple of scripts by moving first to our extracted folder by entering the following command on the terminal (plus enter):
Code:
cd /sdcard/RemoveKing/
To run the first script type (then press enter):
Code:
./step0.sh
It just takes 3 seconds, then type the following and press enter:
Code:
./step1.sh
This last script will ask for a confirmation during its process.
Type just an "y" and hit enter: (WARNING, the Y won't appear on your display after typing it)
Code:
y
You'll notice a bunch of errors, don't mind them.
Installing SuperSU
Now hit the home button and go to the play store.
Search and Install SuperSU (free version). Open it. Choose Expert.
The app will ask "The SU binary needs to be updated, continue?".
Hit Continue and then choose "Normal" when asked on the next popup.
You'll receive an "Installation Sucess!". Tap the Reboot option.
Congratulations! You are now rooted with SuperSU.
After rebooting, enter the Terminal app once more, and tap the X on the right upper corner and hit OK.
That will finish the current terminal session.
If you're interested in getting Xposed Framework, go to part 3 of this guide.
If you're just interested in debloating the SM-T707A and improve its performance, go to part 4 (Soon).
Part 5 is where I discuss the modules I'm using on Xposed and also some Playstore apps to improve functionality, and remove as much Touchwiz as possible, while also working on better battery life (Soon too).
Final Considerations (suggested reading - not mandatory)
While this guide may seem easy to carryout, it took me almost a month to get SuperSu to work on Lollipop.
I'm no coder (a soon to be Certified Public Accountant), and the real magic to pull this off was to try many combinations of different app versions, different situations with google services and several strategies with the script and superSU. In fact, most of KingRoot versions don't work on this tablet to get root, also tried SuperSume app from the playstore. The same could be said for KingoRoot (don't confuse it with KingRoot), it worked but I couldn't remove it without losing root.
Why I'm telling you this? Because using KingRoot and similar apps to root this tablet, your mileage may vary while doing it. In fact, even while applying my first two guides there's a respectable chance of KingRoot tool failing to root your tablet. If you followed this couple of guides to the last comma, your chances of success are very close to 100%. But I have noticed in similar Galaxy Tab S threads, that the use of KingRoot and KingoRoot to achieve root is just a matter of using the root tool many times until it works, and I wanted to avoid you guys going thru that. To take sucess rate as close as it gets to 100%, we took all of this steps. They were included to avoid many failures. I believe they're are 99% flawless to achieve root on Lollipop with SuperSU.
Also, the second script won't remove many KingRoot files, because it was thought for KingoRoot on KitKat.
I have to give myself more time to develop something that could really clean up the last traces of KingRoot.
Special Thanks
* @chixvicious - For showing how to achieve the same over KitKat and KingoRoot instead.
* @bakageta - For creating these scripts for the Alcatel smartphone over KingoRoot.
* @Kingxteam - For developing KingRoot to allow us to root our device.
Oh wow, I had forgotten all about those scripts. Glad to see someone getting some use out of them.
bakageta said:
Oh wow, I had forgotten all about those scripts. Glad to see someone getting some use out of them.
Click to expand...
Click to collapse
They were life-savers, thanks a lot for them!!
Broken links?
First and foremost, thank you for the thorough walkthrough.
I've come across an issue with the provided links to KingRoot and RemoveKing. When I click on either, I receive the following message:
"Invalid Attachment specified. This can happen for a variety of reasons-- most likely because the thread or post you are trying to view has been moved or deleted. Please return to the forum home and browse for another similiar post."
Do you have any alternate links available?
EDIT: I did find an alternate method that worked for proper replacement of KingRoot with SuperSU. All good, and glad for the compatible xposed framework.
zopert said:
First and foremost, thank you for the thorough walkthrough.
I've come across an issue with the provided links to KingRoot and RemoveKing. When I click on either, I receive the following message:
"Invalid Attachment specified. This can happen for a variety of reasons-- most likely because the thread or post you are trying to view has been moved or deleted. Please return to the forum home and browse for another similiar post."
Do you have any alternate links available?
EDIT: I did find an alternate method that worked for proper replacement of KingRoot with SuperSU. All good, and glad for the compatible xposed framework.
Click to expand...
Click to collapse
Thanks for the heads up!!. I'll check them ASAP.
EDIT: All links are fixed!!
kainanmaki said:
Thanks for the heads up!!. I'll check them ASAP.
EDIT: All links are fixed!!
Click to expand...
Click to collapse
Man, can't thank you enough for this...So great for someone like me with little knowledge for all this magic. I am gonna do this when I get back from vacation. Can't wait for the rest of it!
Thanks again
ElCid43 said:
Man, can't thank you enough for this...So great for someone like me with little knowledge for all this magic. I am gonna do this when I get back from vacation. Can't wait for the rest of it!
Thanks again
Click to expand...
Click to collapse
I hope to get part IV and V in no more than 10 days...
I'm in the process of testing removing/freezing many services, just a sneak preview:
So far I was able to disable close to 180-190 apps/services from a total 250-260 (can't remember the exact number).
Of course there are some key services removed (for e.g multi windows, but that's just one service).
Still you can easily remove like 165 without losing any stock functionality. That's how much bloated the tablet is.
Removing useless stuff from samsung and 3rd party (eg. VPN, Policy Updates) or more evident like MultiWindow, the gallery app or even the file browser.
Or the weird ones like the phone app that is hidden and you can't use (you can disable it and still keep LTE Data).
More to come.
Need Help - Having Untimely Reboot Issues
Wow...Thanks SO MUCH for this guide! It gives me hope that I can actually enjoy using my T707A to the fullest!
Alas, I need some assistance PLEASE:crying:
I'm following your guide to the letter, and I've successfully achieved Part 1. Part 2, however, alludes me even after many, many tries. Here is what is going right and wrong:
a) Achieved root with KingRoot
b) installed and achieved SU with Terminal
c) ISSUE - KingRoot (or something) reboots the tablet during Uninstall, which kills SU access obtained with Terminal
d) ISSUE - after reboot, I no longer have permission to run the scripts to uninstall KingRoot
Is there another way for me to do this? As long as the tablet is rebooting during uninstall of KingRoot I have no SU access, so can't do anything but start over and experience the same thing time after time.
ANY assistance would be so very much appreciated...MOST humbly & sincerely...Tom
Where did you find the alternate method??
zopert said:
First and foremost, thank you for the thorough walkthrough.
I've come across an issue with the provided links to KingRoot and RemoveKing. When I click on either, I receive the following message:
"Invalid Attachment specified. This can happen for a variety of reasons-- most likely because the thread or post you are trying to view has been moved or deleted. Please return to the forum home and browse for another similiar post."
Do you have any alternate links available?
EDIT: I did find an alternate method that worked for proper replacement of KingRoot with SuperSU. All good, and glad for the compatible xposed framework.
Click to expand...
Click to collapse
Hi...I am VERY interested in your "alternate" method for replacement of KingRoot with SuperSU that actually worked. Would you be so kind as to share that with me? I'm having huge troubles (see my post) replacing KingRoot as it reboots thus killing my SU access necessary to run the uninstall scripts provided in OP. Any help would be GREATLY appreciated. MOST humbly & sincerely...Tom
TomandJonna said:
Wow...Thanks SO MUCH for this guide! It gives me hope that I can actually enjoy using my T707A to the fullest!
Alas, I need some assistance PLEASE:crying:
I'm following your guide to the letter, and I've successfully achieved Part 1. Part 2, however, alludes me even after many, many tries. Here is what is going right and wrong:
a) Achieved root with KingRoot
b) installed and achieved SU with Terminal
c) ISSUE - KingRoot (or something) reboots the tablet during Uninstall, which kills SU access obtained with Terminal
d) ISSUE - after reboot, I no longer have permission to run the scripts to uninstall KingRoot
Is there another way for me to do this? As long as the tablet is rebooting during uninstall of KingRoot I have no SU access, so can't do anything but start over and experience the same thing time after time.
ANY assistance would be so very much appreciated...MOST humbly & sincerely...Tom
Click to expand...
Click to collapse
I had that problem many times, the uninstall reboots the tablet before you can establish SuperSu.
The most reliable way I found of overcoming this is to follow the exactly in this order and without stopping to much because google wants to run updates behind scenes that mess with our process (that's why sometimes it works and sometime it doesn't). My recommendation is to start over from scracth again (I know it's boring). I'll probably do it again on my tablet just to validate and to try some other things related to the original services).
TomandJonna said:
Hi...I am VERY interested in your "alternate" method for replacement of KingRoot with SuperSU that actually worked. Would you be so kind as to share that with me? I'm having huge troubles (see my post) replacing KingRoot as it reboots thus killing my SU access necessary to run the uninstall scripts provided in OP. Any help would be GREATLY appreciated. MOST humbly & sincerely...Tom
Click to expand...
Click to collapse
Other thing I forgot to ask, did you started clean from the first part or just started with part 2 of the guide?
Will this method trip Knox?
i need * RemoveKing file now...

Security issues surounding bootloader unlocking and installing custom recovery

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.

Question [ROOT] Editing file build.prop

Hello,
Has anyone tried to modify the build.prop file on the OP10?
Like, audio.safemedia.bypass=true to remove the high volume warning (I don't know if it actually works)
If you know of any other cool lines to add feel free to share them here
Did you manage to edit it, I attempted however found the build.prop stops some access needed to allow r/w to the system
Line needed being:
ro.debuggable=1
So you want to add the line via
Magiskhide
you can add custom lines via terminal after the reboot
ALT Option
Flash
Mod
I didn't know about these solutions, I'm going to look into it.
Thanks
To save some time the first option , possibly due to how it loads the config does disable fingerprint. Assuming default setup.
(I did go in-depth with setting up the fingerprint details for the first module but for some reason the line to disable the audio warning just breaks it)
I did not try delayed as i kept trying all sorts of other options. The second however works with the fingerprint with no tweaks however i personally removed two lines for the stepping of the volume , keeping the line to disable the warning.
In summary, remove the first module if you have done it and experience the fingerprint issue, reboot twice to clear system cache, reinstall the first module but don't put in the custom line via terminal.
(leave setup in the zip as it won't be active till terminal activation, saves time)
Install the second module and reboot. You get safety net pass and the warning disabled.
I had to mess around with this as it was annoying me, i had missed the issue due to doing the pattern password then rebooting ect so i didn't realize the fingerprint issue till a hour later

Categories

Resources