[9.0] Different passwords for encryption and lockscreen - Android Q&A, Help & Troubleshooting

Hi all,
I have a question about encryption on Android 9. I recently fixed up my old Nexus 5 to use as a test device and set it up with the newest Unlegacy Android (Pie) ROM (OpenGAPPS Mini, Magisk 17.1) and enabled encryption on it. So far so good and everything works perfectly without any Problem.
As I was always curious about changing the encryption password on my current daily driver (Nexus 6) because I use a fairly short passcode to not make it annoying to get into the phone, I searched a little and came across the App SnooperStopper, which would do everything I wanted: Make it able to use different passwords for encryption and the lock screen, but also secure the lock screen in a way that after some failed unlock attempts the phone would reboot, requiring the full encryption password again.
After testing on my Nexus 5 I found out that the way the app changes the password does not work on the newer Android OSes anymore. (I also tested the method mentioned on this XDA Blog post without success)
So my question is if there is an updated way to change encryption password or if there is any other way to achieve my goal of having different passwords for encryption and lock screen as well as making the phone reboot on too many retries.
Thanks a bunch!
~Joe

Maybe a bit late, but it might help someone else, as I was looking for a way in Oreo or later the last 2 days too.
bastei said:
As a workaround on Android Pie, you can do the following (on your own risk):
set the desired password for the screen lock
backup lockscreen files:
all files under /data/system_de/0/spblob/
files containing "_synthetic_password_" in /data/misc/keystore/user_0/
/data/system/locksettings.db
set the desired password for the device encryption
restore / replace all lockscreen files
If something went wrong, sqlite into /data/system/locksettings.db and set the values of sp-handle and lockscreen.password_type to 0 to reset the screen lock.
Click to expand...
Click to collapse
For me this did not work and just made the phone hang for a while and then reboot after entering the encryption password.
An alternative way I found was to set a password normally (the one you want for the disk encryption) and then just delete all these files and restart the process of setting a new lockscreen password while denying to turn on the boot protection. This might work on some devices, but according to the following link, this doesn't work for example on LineageOS 16.
Also it seems like LineageOS 17 and possibly other Roms reenabled the old way of changing the password in the Terminal. See: https://github.com/nelenkov/cryptfs-password-manager/issues/25
I wished I could do it without installing any apps, but I am not knowledgeable enough to proceed further. For me the only solution was this modified version of the cryptfs App. The normal install process is explained there as well: https://github.com/thedroidgeek/cryptfs-password-manager/releases
Here is how I installed it:
1) Install the App
2) Get the 'App Systemizer' module through the Magisk Manager (https://forum.xda-developers.com/apps/magisk/module-terminal-app-systemizer-ui-t3585851)
3) Install Cryptfs App normally
4) Run 'systemize' as root in a Terminal app (I got a busybox error and ignored it)
5) Choose 'Systemize Installed Apps (Listed)' and find 'Cryptfs Password'
6) install into '/system/priv-app'
7) For me it errored out saying that the app already exists, ignore it.
8) reboot
9) Start Cryptfs App. If the process of making it a system app failed, then the app shuts down with an error message about needing to be systemized.
10) set your encryption password in the app.
11) Reboot, check if it works
12) Disable cryptfs App and the App systemizer module, no need to keep them running until next use.
The difference to snooper Stopper is that you can't set any actions to take if the password is entered incorrectly a few times. However if that functionality is needed, you can install snooper Stopper afterwards and just ignore the password change options and just set the behaviors.

Related

Don't trust Full Disk Encryption

Context
Android uses the same PIN (or pattern) that is used to unlock the screen to decrypt the disk. However the actual decryption key is bound to the device via some internal device key. So ideally you can only decrypt the disk on the device itself, and the device can delay the process and ultimately delete any data if too many failed attempts are made. This is the same concept that's used e.g. on ATM cards, which lock themselves after a couple of failed attempts, so a 4 digit PIN is enough.
Except that's not true, at least not for Qualcomm chipsets, where you can extract the device key, than brute-force the PIN externally, which shouldn't take too long for a 4 digit PIN. See [1]
So I want a strong password for disk encryption, but still a 4 digit PIN for unlocking. I tried the Cryptfs-app, but that crashed, so I used the "vdc cryptfs changepw ..." command on the commandline to set the disk encryption key. On the next reboot, the phone asked for my password, but didn't accept it. So reset everything, and try again. I did this a couple of times with the same result but ultimately got it work by making data not encrypted and then encrypt it using "vdc cryptfs enablecrypto ...".
Not sure exactly what went wrong there, but I saw a couple of QSEECOM errors in the log (QSEECOM is the component that communicates with Qualcomms "secure" execution environment).
This is on a BQ Aquaris X with TWRP and SuperSU but otherwise stock firmware (Android 7.1.1).
The worrying part
Now here is, what worries me: Whenever the phone didn't accept my (correct) password, I rebooted into TWRP. TWRP then asked for my password to decrypt data, and did so successfully. Except it also worked with the wrong password! Apparently during the boot process, when Android asked for my password, it actually decrypted the key and kept it decrypted over a full reboot! Some component didn't get properly reset. I checked by entering the wrong password during boot. When I then rebooted into TWRP I actually had to enter the correct password for it to work.
Now, that the system is working (i.e. it actually continues to boot after I enter the correct password), I cannot reproduce that behaviour. A reboot seems to always clear the key. But who knows, maybe with some trickery it is still possible to keep data decrypted over a reboot. Given how buggy the implementation seems to be.
Question
Is anyone aware of a known bug where the disk encryption key is kept decrypted over a reboot? I couldn't find anything about this.
Conclusion
Use a strong password for disk encryption
Even if you do, don't trust your phone and don't keep real sensitive data on your phone
harry
[1] (can't post links, so google for: Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption blogspot)
3 years later on Android 10 it seems like this issue still exists? And I wondering why encryption is even enabled because it offers basically not protection.
The only workaround in Android 10 that I could think of:
I can use faceunlock for the lockscreen and for the decryption after a boot up. So basically I never really ever have to enter my PIN or pattern.
That means I could use a really strong and complicated PIN or pattern and there for increase the security of the encryption.
How ever, even a 12 digit numerical PIN or pattern (a pattern is basically just a numerical PIN) won't take long to bruteforce.

[GUIDE][TWRP-zip] Remove all locksettings from lockscreen

This is mostly common knowlegde by many users and already explained in another topic but in the last couple of days i needed to help some guys with a lockscreen problem like wrong PIN, pattern or password for whatever reason it started.
Instead of deleting some files I made a small flashable zip which can be held on your extSD in case something might go wrong in future
Normally with deleting in twrp file manager : /data/system/locksettings.db you would be good to go.
In other cases you might need to delete :
/data/system/gatekeeper.password.key
/data/system/gatekeeper.patern.key
/data/system/locksettings.db
/data/system/locksettings.db-shm
/data/system/locksettings.db-wal
Anyway, just flash this zip : A2017X_remove _all_ locksettings NEW VERSION due to typo - thnx @dnlilas
......and password, pattern and pin will be removed :good:
Btw, if you have FP + pin, pattern or password and apply this zip, only the FP remain. Pin, pattern or password are gone.
Tested on G version. Should work on U/CN too although in some cases it had no effect. Just try and see
Thanks. It worked on a Note 3 SM-N900P i was unlocking for a customer. Lucky me i was able to install TWRP and it didn't force me to do a factory reset so i could avoid resetting it from recovery menu thus triggering on the Samsung lock status. I guess security on those days was none to zero. I feel confident that the route i took to remove the pattern is not available on newer phones/ android versions.
THX!
Does it also work if TWRP can 't mount the system partition due to password protection?
@raystef66
Just for information: there is a typo in updater-script:
delete("/data/system/gatekeeper.patern.key");
instead of:
delete("/data/system/gatekeeper.pattern.key");
dnlilas said:
@raystef66
Just for information: there is a typo in updater-script:
delete("/data/system/gatekeeper.patern.key");
instead of:
delete("/data/system/gatekeeper.pattern.key");
Click to expand...
Click to collapse
Good find ! Indeed there is
A2017X_remove+_all_+locksettings
hello community ,
Do I need Twrp in phone ?When I want use the script ?
How to use this script ? I must rebulid fota and paste script ?
best regards .
My phone is stuck in "phone is starting" screen, i can open settings app from the quick settings but i cant open any apps from the settings
Nokia 7.1
Havoc-OS Android 10
Removed PIN

What happens if you delete the Lock Settings files on an encrypted device?

Assume that one has a device that:
Running a version of Android that is either Nougat, Oreo, or Pie.
The device uses not full disk encryption but rather file-based encryption.
Has a password, pattern, or PIN set.
Say that the user has booted into TWRP or something like and deletes each of these files if they exist:
gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksetting.db-shm
locksettings.db-wal
Here are my questions:
Upon booting into stock Android, will Android be able to load correctly? If not, what should it be expected to do?
I've seen on here and other websites users who did something similar to what I described and were unable to get to their applications/files BUT were able to access Settings. If this is what should be expected to happen, then what will happen if one sets another lock code through Settings? Will it erase the blob data connected to the old lock code that plays a role in deriving the decryption key? Will it crash instead?
Master Melab said:
Assume that one has a device that:
Running a version of Android that is either Nougat, Oreo, or Pie.
The device uses not full disk encryption but rather file-based encryption.
Has a password, pattern, or PIN set.
Say that the user has booted into TWRP or something like and deletes each of these files if they exist:
gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksetting.db-shm
locksettings.db-wal
Here are my questions:
Upon booting into stock Android, will Android be able to load correctly? If not, what should it be expected to do?
I've seen on here and other websites users who did something similar to what I described and were unable to get to their applications/files BUT were able to access Settings. If this is what should be expected to happen, then what will happen if one sets another lock code through Settings? Will it erase the blob data connected to the old lock code that plays a role in deriving the decryption key? Will it crash instead?
Click to expand...
Click to collapse
How about you set the conditions and try it out yourself
([emoji3590]09-09-18[emoji3590])
PoochyX said:
How about you set the conditions and try it out yourself
([emoji3590]09-09-18[emoji3590])
Click to expand...
Click to collapse
Because I don't have a functioning Android device that meets the requirements I outlined.
I am bumping this thread.
Bump.
**DONT**
did the same thing "accidently " a while ago, had to format /data (internal storage is gone!)
My device was struck on "Wait a second" forever.
It worked before file-based-encryption, but now I think the android system (Gatekeeper maybe?) checks for locksettings.db file during the bootup and doesn't start if not found or something
PS: Don't delete any of these files if your system uses file-based-encryption
locksettings.db
locksettings.db-shm
locksettings.db-wal.
file-based-encryption actually requires your PIN (used to encrypt) to decrypt the file-system, in addition it requires a lot of other ce/de key files, my advice would be not to delete stuff without making a proper backup!

[Magisk Module] Xiaomi Redmi Note 3 Pro - Lockscreen fix - Alpha (Android 9,10)

Found it to be ineffective against the latest lockscreen bugs.
Code:
I have made an attempt to fix the lockscreen bug that happens randomly on the kenzo (ie when you go to enter the pin number, the lock screen will keep appearing no matter if you input the correct value.) eventually you will have to delete the locksettings.db file to reset it so you can boot into the phone.
I have made a Magisk module that sets the locksettings.db file read-only meaning nothing can modify the file ('something' causes it to corrupt and develop the bug), unfortunately just setting it read-only will cause the OS not to boot so I had to set it read-write on boot then set it read-only after boot finishes., this is a quick 'fix' , I had several people test including myself and so far the bug has not appeared again, so it might just be luck or it's a effective fix, I put a 20 second delay on before setting it read-only so it might be possible for the bug to develop within this timeframe, but unlikely unless the system crashes on boot. so please make sure the system is stable before using the module.
Preliminary checks.
First make sure you currently don't have the 'bug' if you do flash a lock screen reset or delete locksettings.db, then setup a working lock screen., after you are satisfied, you can flash this module.
Bugs that might come from this module.
1. since it sets the file read-only, changing the lockscreen type or password might not work, you must disable the module, and either delete locksettings.db (from twrp), or change the permissions back to 660, then make your changes, then re-enable the module and reboot. - so I suggest using this module if you don't frequently change the lockscreen type or password/pattern/pin. I intended this to be a set and forget kinda fix.
2. I suspect a softreboot or systemui crash might cause the system to get stuck in a loop (untested) but I figure if it's the same as a normal reboot with it set readonly it will get stuck, if that happens then a force reboot might be necessary (power buttons pressed for 10 sec). again I am unsure if this will happen but there is a possibility.
3. Unknown, let me know.
Uninstall.
I had made this module for myself initially but figured more people might benefit from it (if it works), so uninstall / disable the module might require some manual fix-ups, so if you have problems here are the steps you should follow.
first reboot to twrp, go to /data/adb/modules/rn3plsf/ and delete the folder (this effectively disables the module, or you can use the orangefox magisk manager to disable / remove) , then go /data/system/locksettings.db and set permissions to 660 (you can also delete the locksettings.db file if you want to start new), reboot & everything should be as it was before.
I have only tested this on Android 10 (msm xtended), I am unsure if it will work on lower android versions, don't try it on selinux builds or miui. (well you can but it probably won't work)
-
This work is ALPHA, I expect the user to know how to use twrp and modify / delete files and are ok with experimenting, I may fix-up the module or make a uninstaller at a later date if it has good results, but for now I am just testing this. [B]use at own risk[/B],. I hope I have found a fix, but results are still to early to tell. please test and report back.
I don't check xda everyday, sometimes it can be weeks before I check I am pretty busy .
Thank you, this bug is the only thing that holded me from using Q roms.
Sir, I had installed this module but the bug still appeared the next time I booted after updating the orange fox recovery..
But after a forced reboot things went fine.
Will inform here next time I face the bug...thanks for the module anyways..
uploaded v2 and a uninstaller.
I lowered the wait time to 8 seconds, I am hoping this is not too quick, on my system it is fine, but I am not sure how it will work on other systems.
sometimes, If I reboot the device fingerprint is not working and If I tried to unlock with pattern it just hangs .. I have to Force reboot it (sometimes more than once) to enter the Home screen. will this module fix this also ?

Samsung Android 11 stock to no-Google MicroG based privacy reconfigure step by step

Two years after my previous guide for Android 10, this is Niall's modernised guide to reconfiguring stock Samsung S10 Android 11 into a privacy focused MicroG based system purged of the stock spyware and annoying and useless stuff, but with the actually useful Samsung Apps such as Camera, and VoLTE remaining fully functional. Don't get me wrong here, LineageOS on the S10 is better in all ways especially in regular security updates, but the current LineageOS camera experience just can't compete with Samsung's deep integration of camera software and hardware. I therefore reluctantly offer this guide as a stopgap until LineageOS gets a better Samsung camera experience.
NOTE: The previous version of this guide for Samsung S10 Android 10 can be found at https://forum.xda-developers.com/t/...sed-privacy-reconfigure-step-by-step.4174691/. Before anyone asks, no I don't have a guide for Android 12, nor do I expect to make one for at least a year from now (I trail major Android releases, I don't lead them, it's too much work!)
After completing this guide, you will have only these apps left installed visibly in the launcher:
Aurora Services and Aurora Store (to replace Play Store)
Brave privacy web browser + Bromite privacy web view
Samsung Calendar
Samsung Camera
Samsung Clock
Samsung Contacts
F-Droid
Samsung Gallery
Magisk Manager (root, customisations etc)
Google Maps (retained only due to its great usefulness for public transport)
Samsung Messages (for text messages)
microG Settings
NextDNS to prevent even more personal data leakage (and optionally ads)
Samsung My Files
OsmAnd (for offline navigation)
Samsung Phone
Samsung Settings
Samsung Launcher and its Recent Apps switcher, as with a bit of reconfiguring it's not too bad actually.
Upon each boot you can choose whether you will have root via Magisk by booting your phone with the correct buttons pressed (Volume Up + Bixby + Power, but released after the boot screen). There is no need to run with root available, per boot, unless you want it. This makes my solution markedly superior in my opinion to the more popular Magisk + Zygisk + LSposed + FakeGapps MicroG approach which relies on injecting code into every app you run, which in turn requires you to always boot with root enabled. Personally speaking, I am also not comfortable with injecting code into my banking apps etc.
The principle things removed from stock are:
Samsung AR stuff
Samsung Bixby (apart from QR codes and Routines which are useful)
Google Chrome (it keeps hanging and stalling if used with MicroG, and besides it leaks your browsing habits)
Google GMail
Facebook (all traces)
Google YouTube (you ought to use NewPipe from F-Droid instead)
Samsung App store
Samsung Games home app
Microsoft OneDrive
Samsung Tips
Samsung DexOnPC (it spams you with messages)
Samsung EasySetup (also spams you with messages)
Samsung Edge Panel (the swipey translucent tab which floats above at the top right and gets in the way of taps)
Google Play Store
Google Accounts
Google Services
Note that this is NOT a deep "debloat", I only removed the bits you can see, which make themselves noticeable, or stuff known to leak your information to others. I left everything else alone, even if on most common "debloat" lists for the S10.
I also didn't remove ALL of the annoying popup notification Samsung stuff in this guide, unlike for my Android 10 guide. This is because removing all of it breaks the Samsung TouchWiz launcher which my Android 10 guide completely replaced. Besides, Android 11 is good at letting you suppress annoying notifications caused by things really wanting you to activate them e.g. "Find my Mobile", which requires a Samsung account.
This guide uses Nanodroid, which has a reputation for installing lots of stuff you don't want, which puts a lot of people off using it. As of recently, Nanodroid now offers small, single purpose, packages which you individually combine to get what you want. So no more random ringtones nor backdrops being installed that you don't want!
You should be warned that this conversion leaves your device insecure. OTA updates from Samsung self disable as soon as you modify any system image, so you'll need to manually go retrieve new firmwares and repeat the below instructions (obviously flashing HOME_CSC instead of CSC to not factory reset the device) to stay secure.
Privacy achieved limitations (so you know what we can't keep private)
As with any device with a mobile (cellular) connection, as soon as you see a mobile phone (cell) signal, your position is exposed as they can track you by IMEI. Outside the EU, your historical, and sometimes current, location data is routinely sold for money by your provider to commercial third parties. Within the EU, your mobile provider is not supposed to expose your location to anyone but law enforcement without your explicit permission, but some providers are still catching up with GDPR and still relying on implicit permission buried deep inside EULA text. In any case, as soon as you see a mobile phone tower with your phone you have declared your position, and only airplane mode prevents that. This is unavoidable no matter how you configure any device capable of interacting with mobile phone masts.
Google Maps obviously leaks your location and movements to Google as soon as you open it, so you should prefer to use OsmAnd for offline maps and navigation whenever possible. Equally only Google Maps can route over public transport, knows when buses will arrive etc, so that's why I've kept it. Use judiciously!
MicroG needs to register with Google for push notifications, otherwise stuff like WhatsApp doesn't work. MicroG leaks as little information about you as it can, but ultimately Google can see from where you register including if by wifi alone, and thus determine your coarse location. You may wish to consider a VPN if you wish to obscure your physical location.
As much as you may secure your phone, individual apps you install may leak a great deal about you. For example most apps for tracking ovulation and when you have sex sell your personally identifying data and when you do it to others for money. You personally may not install such apps, but if anyone enters your private information into any phone, then your information is leaked. That information is composed into commercial databases which record everything about everyone. Is this paranoid? Note I said commercial databases. Most western governments are prohibited from mass survellience, so they simply buy the data from private firms which aggregate everything there is to know electronically about you. Amongst the many companies providing such service are Experian (you can request a dump of what they know about you, prepare to be disgusted) and Palantir (legislation hasn't caught up with them yet).
Finally, even if you are always in airplane mode, and all your friends and loved ones are as aware of personal data leakage as you are, ultimately this is a losing fight. Every time a CCTV camera facial recognises you, every time a satellite tracks your car, it's all being aggregated into databases about everyone, and more importantly, whom everyone has relations with. Even the device-less person is recorded, studied, tracked, and inferred from by algorithms. There is only so much any of us can do.
Instructions
Preparation: go find APKs for the following:
Magisk Manager. Rename it to MagiskManager.apk.
You really ought to insert a micro sd card. It makes life vastly easier when wiping the device, and this guide assumes that you have inserted one.
Make sure your bootloader is unlocked and your device has been configured to accept unofficial binaries. You can find instructions for how to do this at https://topjohnwu.github.io/Magisk/install.html#samsung-system-as-root. You will need adb shell working with your device in Developer mode.
First install: In Odin, flash your choice of stock Android 11. Flash all parts, choosing CSC not HOME_CSC for the CSC slot in order to ensure a factory reset. Do NOT skip this complete reset to stock. Optional: Boot into stock firmware, enable wifi, and download and install any security updates available. Do NOT upgrade to One UI 4.0 or later (that is Android 12 or later, this guide is written for One UI 3.5/Android 11 only)
Upgrade: In Odin, flash your choice of stock Android 11. Flash all parts, choosing HOME_CSC not CSC for the CSC slot in order to prevent a factory reset. Do NOT let the device try to boot into the system, it will wipe your data!
You will need to reboot the downloader for the next step. Be aware that if you are upgrading and you mess this up even just once, all existing data will be wiped and you'll need to start again as if first install. With a USB cable connected to the computer, you need to hold volume Down, Bixby and Power to boot into Download. If it goes to screen dark and doesn't continue, try releasing Power.
Restart Odin, then flash AP slot with the TWRP TAR archive and the CP slot with the vbmeta.tar using images and instructions from https://forum.xda-developers.com/t/...-0-x-twrp-for-galaxy-s10-e-5g-exynos.4180287/.
Boot into TWRP recovery using Volume Up + Bixby + Power On by holding them down until the recovery starts. This can take multiple attempts. It may be useful to know, if stuck on the first boot Samsung logo (you don't need to worry about interrupting first boot right now), that holding volume down and power button for long enough will force reboot the device.
First install: In TWRP format data. Do NOT skip this part. This removes Samsung's encryption of the internal sdcard so you can take backups of your data etc in TWRP.
Upgrade: Do NOT format data, for obvious reasons.
In TWRP install the multidisabler zip available from https://forum.xda-developers.com/t/...-0-x-twrp-for-galaxy-s10-e-5g-exynos.4180287/.
Put into a file called .nanodroid-setup:
Code:
nanodroid_nlpbackend=1001
nanodroid_play=21
nanodroid_gsync=0
This custom .nanodroid-setup adds the install of the radiocells location backend (this uses a downloaded on-device database of mobile phone mast ids to locate you), and prevents the install of the Google Sync Adapters which prevents Google getting your contacts list and calendar.
In TWRP mount Product, System and Vendor.
Do the following from your PC with TWRP still running:
Code:
adb shell
rm /system_root/system/app/ARZone/ARZone.apk
rm /system_root/system/app/BixbyWakeup/BixbyWakeup.apk
rm /system_root/system/app/FBAppManager_NS/FBAppManager_NS.apk
rm /system_root/system/app/Facebook_stub/Facebook_stub.apk
rm /system_root/system/app/YouTube/YouTube.apk
rm /system_root/system/priv-app/Bixby/Bixby.apk
rm /system_root/system/priv-app/BixbyAgentStub/BixbyAgentStub.apk
rm /system_root/system/priv-app/BixbyService/BixbyService.apk
rm /system_root/system/priv-app/GalaxyAppsWidget_Phone_Dream/GalaxyAppsWidget_Phone_Dream.apk
rm /system_root/system/priv-app/GalaxyApps_OPEN/GalaxyApps_OPEN.apk
rm /system_root/system/priv-app/GameHome/GameHome.apk
rm /system_root/system/priv-app/FBInstaller_NS/FBInstaller_NS.apk
rm /system_root/system/priv-app/FBServices/FBServices.apk
rm /system_root/system/priv-app/EasySetup/EasySetup.apk
rm /system_root/system/priv-app/OneDrive_Samsung_v3/OneDrive_Samsung_v3.apk
rm /system_root/system/priv-app/Tips/Tips.apk # stupid Samsung Tips popups
rm /system_root/system/priv-app/DeXonPC/DeXonPC.apk
rm /system_root/system/priv-app/CocktailBarService_v3.2/CocktailBarService_v3.2.apk # Edge panel top right floats
rm /system_root/system/app/Chrome/Chrome.apk
rm /system_root/system/app/ChromeCustomizations/ChromeCustomizations.apk
rm /system_root/system/app/Gmail2/Gmail2.apk
rm /system_root/system/app/GoogleCalendarSyncAdapter/GoogleCalendarSyncAdapter.apk
rm /system_root/system/app/GoogleContactsSyncAdapter/GoogleContactsSyncAdapter.apk
rm /system_root/system/app/GoogleLocationHistory/GoogleLocationHistory.apk
rm /system_root/system/system_ext/priv-app/SetupWizard/SetupWizard.apk # Without removal never passes initial setup
# New annoying popping up stuff in Android 11
rm /system/priv-app/ConfigUpdater/ConfigUpdater.apk
rm /system/priv-app/KnoxPushManager/KnoxPushManager.apk
rm /system/priv-app/SamsungAccount/SamsungAccount.apk
rm /system/priv-app/SPPPushClient/SPPPushClient.apk
# Stuff replaced by MicroG
rm /system_root/system/priv-app/GmsCore/GmsCore.apk
rm /system_root/system/system_ext/priv-app/GoogleServicesFramework/GoogleServicesFramework.apk
rm /system_root/system/priv-app/Phonesky/Phonesky.apk
rm /system_root/system/priv-app/Velvet/Velvet.apk
exit
adb push .nanodroid-setup /sdcard/
All the removed apps free up enough space on the priv-app partition to install the Nanodroid apps coming next, so the above step isn't really avoidable. You also need to repeat it after any firmware upgrade.
(Incidentally, if you want to figure out what other apks to prevent being installed on first boot, once installed from adb shell do
Code:
pm list packages -f
and it will print all installed apks and the path from where they came. If that isn't enough to track a bloatware package down,
Code:
adb shell dumpsys package packages > all_package_info.txt
will give you a searchable text file of detailed information)
In TWRP install exactly these individual packages from https://gitlab.com/Nanolx/NanoDroid:
NanoDroid-BromiteWebView-23.1.2.20210117.zip
NanoDroid-fdroid-23.1.2.20210117.zip
NanoDroid-microG-23.1.2.20210117.zip
NanoDroid-OsmAnd-23.1.2.20210117.zip
(Later, but not earlier, versions will probably work fine too)
Try installing in TWRP NanoDroid-patcher-XXX.zip. If it works (the 23.1.2.20210117 version did not for me), great. If it doesn't, you'll need to manuall do the patching, see below for how to do that.
Reboot into System. It will get stuck on the Samsung boot logo for a while, but will eventually open onto either the enter Samsung account stage of setup, or the Setup All Done stage (we earlier removed all the earlier parts of setup). Hit Skip and/or Finish to reach the Launcher. Enable wifi and connect to your wifi connection.
Enable Developer Mode by entering Settings => About Phone => Software Information then tap the Build Number ten times. In Developer options, enable USB debugging and authorise your PC via USB cable.
If NanoDroid-patcher failed to work earlier, we need to do the patch by hand via root. Install MagiskManager.apk using
Code:
adb install MagiskManager.apk
. Extract the TWRP recovery.img from the TAR file and copy it to the sdcard, then open Magisk Manager with a wifi connection active. Choose install. Then choose Select and Patch file. Patch the TWRP img previously copied. Magisk Manager will output a root patched img into Downloads. Copy that back to the PC. Make a new TAR file of that. Flash that in Odin in the AP slot. Boot the device using Volume Up + Bixby + Power, but release as soon as the bootloader warning screen appears, so you boot into the system with root enabled. Go back into Magisk Manager, ensure Magisk appears as installed. If not, reboot and again try the key combination until it works. If in the future root ever appears to have got lost or isn't working, check the Magisk Manager, you probably forgot to hold the right keys during boot.
In Magisk Manager, choose the Modules tab, then Install from Storage. Copy in NanoDroid-patcher-23.1.2.20210117.zip to the device again. Let Magisk install it, it will appear to work, but in fact on your next reboot your device will never start again. Before that happens, copy the patched services.jar out to your PC:
Code:
adb shell
su # magisk will prompt to allow
cp /data/adb/modules/NanoDroid_Patcher/system/framework/* /sdcard/
exit
exit
adb pull /sdcard/org.spoofing.apk
Start again from the top of this guide i.e. reinstall stock, TWRP (but this time flash the rooted patched edition). Once into TWRP format data, mount Product, System and Vendor. Copy out the services.jar file to your PC:
Code:
adb pull /system_root/system/framework/services.jar
Get the Android 11 patch files from https://forum.xda-developers.com/t/signature-spoofing-on-unsuported-android-11-r-roms.4214143/ and execute:
Code:
java -jar dexpatcher-1.8.0-beta1.jar -a 11 -M -v -d -o ./ services.jar haystack-11-attempt\11-hook-services.jar.dex haystack-11-attempt\11core-services.jar.dex
Open the original services.jar in WinRAR and drag in the newly generated classes.dex, classes2.dex, classes3.dex, classes4.dex, replacing the three classes files in there. Your patched services.jar file will now be half the size, for some reason the original one was created without ZIP compression. It doesn't matter, adb push your patched files:
Code:
adb push services.jar /system_root/system/framework/
adb push org.spoofing.apk /system_root/system/framework/
Reboot into system, remembering holding down the keys to enable root for this boot, and reinstall Magisk Manager again.
Once back into the device, open the microG settings app. Run the Self-Check, the "System grants signature spoofing" will be unticked. Tap it, grant permission. The item "Play Store (Phonesky) has correct signature" will also be unticked. Tap that, grant permission. Now the self check should report everything is working and having correct signature. Signature spoofing should be working.
Within MicroG settings, enable Google device registration, cloud messaging and safety net. If you don't enable these, any applications you install next will never receive notifications, ever. Enter location modules. Enable Deja Vu, Radiocells and Nominatim backends. The Deja Vu backend doesn't need configuring, it simply records Wifi and mobile phone mast data and your GPS location when available, and builds a database matching wifi and mast data to GPS. Next tap the Radiocells entry, then Configure, then download offline catalog now, choose your country, then choose offline mode. Now your phone can locate itself purely using an offline database of phone masts and wifi. Next tap the Nominatum entry, then Configure, then choose Nominatum API server, and then OSM.
Open OsmAnd~ the app, choose your country, and download your offline map so you can navigate without an internet connection. Open the app, ensure navigation is working.
Enable and enter Developer options in the settings, open the WebView implementation, and set it to Bromite System WebView.
Go to https://nextdns.io/ and create yourself an account and unique id. From Aurora Store, find and install the NextDNS app. Configure the app with the id you got from your account on the website, and tell it to send your device's name. NextDNS acts as if a VPN for your Android device and thus all internet traffic routes through it, but it blackholes DNS lookup for a configurable list of items in your NextDNS account. Via this, you can block a long list of leakage of your personal information, and also optionally block ads on your device. If you log into nextdns.io from time to time, you will no doubt be fairly saddened by how much of your data is attempted to be leaked all the time.
From Aurora Store, find and install the Brave privacy web browser. As we removed Chrome due to it not working well with this modified system (it keeps stalling), you will need a new system web browser in any case and out of the box, Brave blocks all adverts and tracking. If you enter its settings, you can also disable Javascript by default (only enable it per site on a case by case basis, you can enable temporarily per site, or store an exception). Be aware that if you don't enable Brave rewards, the Brave authors silently pocket any BAT tokens your web browsing earns, so you may wish to enable Brave rewards for the very tiny income generated by your attention if you leave Brave ads disabled (it is local browser only, nothing gets enabled online, BAT tokens are conferred by crypto exchange so none of your browsing gets leaked). Personally speaking, I'm quite keen on the idea of me getting paid personally to see adverts as none of my personal browsing history leaves the Brave browser, even if it's pennies a month, so I leave that stuff turned on.
Brave defaults to regularly pinging you with Android notifications with Ads, which is very annoying, but deep inside the Brave settings you can specifically disable Ads notifications completely.
Settings
You probably want a decent set of settings rather than iterating through the Settings app. These are mine obviously, so you can skip these or not. With Developer Mode enabled, do the following:
Code:
adb shell
settings put global display_size_forced 1440,3040
settings put global navigationbar_key_order 1
settings put secure default_display_density_forced 560
settings put secure display_density_forced 560
settings put secure default_display_size_forced 1440,3040
settings put secure package_verifier_state 1
settings put secure screensaver_components
settings put secure selected_input_method_subtype 65538
settings put secure ui_night_mode 2
settings put system hdr_effect 1
settings put system display_night_theme_wallpaper 1
settings put system screen_off_timeout 300000
settings put system aod_servicebox_page_gravity 17
settings put system aod_show_state 1
settings put system aod_tap_to_show_mode 0
settings put system display_night_theme 1
settings put system hearing_diagnosis 1
settings put system hearing_direction 0
settings put system hearing_musiccheck 0
settings put system hearing_parameters 5,5,5,5,5,5,5,5,5,5,5,5
settings put system hearing_revision 0
settings put system hearing_videocheck 0
settings put system lock_clock_adaptive_colors 'fffaeecd;ffd9faeb;fffae7b4;ffc0fae0'
settings put system qs_detail_content_primary_text_color -2500135
settings put system qs_detail_content_secondary_text_color -1710619
settings put system remote_control 0
This is mainly how I like my settings. I want the actual resolution of my fancy device, not some subset (why bother buying a device with better otherwise?). I want dark theming to take advantage of power saving in my fancy AMOLED screen.
Swype keyboard
Enter Settings, General Management, Samsung Keyboard settings, and then Swipe, Keyboard swipe controls. Enable Swipe to type.
Firmware upgrades
To apply future firmware upgrades, you will need to acquire the latest Samsung firmware for your device from a reputable source. You almost certainly want to take a full backup in Titanium Backup, and copy that backup onto an external sd card to be safe. During flashing in Odin, flash the HOME_CSC, not the CSC, image into the CSC slot. This should preserve all your settings and installed applications. Disable auto rebooting in the Odin options. Then when the flash is done, manually reboot into Download, then repeat all the steps above.
If you do it right, you'll reboot into your device just as you left it, just with all the components upgraded to latest. If you screwed up, that Titanium Backup you made will be very useful.
Not that I'd recommend running out of date firmware images, but I would say that by far the most common upgrade you'll need to do is latest MicroG because Google bumped the minimum version of Play Services its apps will accept, so for example Google Maps will barf about Play Services being too old. There is a very simple fix for this: don't upgrade Google apps! An older Google Maps works just fine even if it's many months old.
Credits
What this guide achieves wouldn't have been possible without the following hard work from many people creating the components I have reused:
topjohnwu
ianmacd
Christopher Roy Bratusek
RandomAJL
mar-v-in
Whomever makes available Samsung Odin and the other stuff which makes LineageOS and AOSP become ever better for the S10 devices.
This is well written. I was familiar with most of this. I tried Lineage, but since VoLTE was not supported, I could not make or receive phone calls.
I got stuck on step 12. At that point, all the zip files were invalid. I was able to do steps 14 & 15, but gave up after 16. I could not install any apps as I had no microG or Aurora. I downloaded the files directly from NanoDroid Christopher Roy Bratusek. Any ideas what I did wrong?
The one difference is I am using an S10e, SM-G970F. I verified it is European, Exynos (I don't think I could have gotten to 12 if it was not). However, the two year ago thread said it should work with the e model.
I downloaded the files from NanoLx and got those installed. I cannot get root. I have tried the key combinations over and over again. I just get booted into TWRP recovery, no matter how soon I release the buttons. I have made many attempts.
It's because so far I cannot successfully Odin the magisk patched TWRP in the AP slot. It never shows any progress.
I patched the file 3 times, every time wi-fi was active. Different SHA256, but all same size. Not one would write in AP slot with Odin. I was able to flash AP with TWRP and CP with vbmeta, so I know how to do it. It will not write this file.
With great persistence, I was finally able to use Odin to write the patched AP file. Odin said success. However, I have tried hundreds of times to get the button combination, and nothing works. I have tried holding all three buttons (up, bixby, power), releasing power and holding up and bixby, and also only holding up. All of these I have tried various lengths of time. I was not able to get magisk root with Lineage, either. I believe I got root with SU, but the app was discontinued and not supported.
I have watched numerous tutorials on the button combination, most of them similar, and tried all of them. Counting the screens (most say 3, some 2), and many other times. Again, hundreds of iterations.
Does anyone have a reliable way of getting magisk root access? I am stuck in the middle of step 16. I restarted at the top with a complete factory reset (CSC, not HOME_CSC). Everything was smooth until the button combination.
Sorry to hear that you have found the going tough. I would say that the guide above hides how many times you need to repeat and rinse when you are writing the guide in the first place. The way I wrote the guide above is basically throw on a movie, one which doesn't require much attention, and in the background almost semi-automatically just keep rinse and repeating the guide until it succeeds. Very occasionally I pause the movie if I need to concentrate on something for a bit. The guide then is just a sequence of very frequently repeated steps.
You sure you are using Magisk to patch the TWRP image and not the system firmware image? The way root works on these devices is that Magisk is installed as a recovery firmware. When you boot with the recovery buttons, it runs Magisk. Magisk then counts down a timer, if the buttons are still held down it'll boot TWRP, otherwise it'll boot the main system with root enabled. If no buttons or the wrong buttons are pressed on boot, then neither Magisk nor TWRP ever get involved, the system boots without root.
Hopefully this makes sense. Also, given some of the Odin flash problems you've seen, I'd suggest trying a different USB cable. I've never found Odin will fail to work if the device is freshly booted into Downloader mode unless your USB cable is flaky. If you leave the device in Downloader mode for too long, it seems to time out. Also, it won't accept a second flash if it's already done a first flash without an intermediate reboot back into Downloader mode.
Hope this help.
I never did get it to work with this method. I did gain root access with
Tutorial : Root Galaxy S10 Series Android 12 One UI 4.1 Stock Firmware
Root Samsung Galaxy S10 Series Android 12, WITHOUT Ramdisk Root Samsung S10+ - S10 - S10e SM-G97xxx, Stock Rom Android 12 - UI 4.1 Latest Version (I tested G970FXXSGHWC2) (Without combination keys for active Magisk after normal restart –...
forum.xda-developers.com
After that, I eliminated google play and used microg with
Samsung Android 11 stock to no-Google MicroG based privacy reconfigure step by step
Two years after my previous guide for Android 10, this is Niall's modernised guide to reconfiguring stock Samsung S10 Android 11 into a privacy focused MicroG based system purged of the stock spyware and annoying and useless stuff, but with the...
forum.xda-developers.com
Thank you for your help.

Categories

Resources