Database Info

Temporary root shell for developers on locked bootloaders.

Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
 @jcadduono - For recowvery, and pointing me in the right direction on IRC.
 @brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.

Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out

I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).

jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.

@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard

@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA

roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.

I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app

We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.

ATT Pretty Please

me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!

NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario

elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid

markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories

Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app

Works on the LG G5 also...

Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA

roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.

LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'

Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim

[SOLVED] Wi-fi "memory" reset on every disabling!

Hello,
I got a little problem with my phone (so freak... I'm explaining)
I got a router before but now I changed it, because I switched to another operator. But it feels like the Wi-fi of my phone is not agree with that.
I "forget" the now inexisting router I had and connect to the new one...
...But I do this each time I turn off then on Wi-fi, and even after switching off the device with enabled Wi-fi!
For now I just have to remember one Wi-Fi router (and, thank you Kika Keyboard developers who made an extensive clipboard where I can store my password <3) but figure out what it will be when I'll have to save more passwords! So yes it's annoying. And I also already lost at leat 8 router passwords because of this strange cr*p.
Fortunately I got a Wi-fi retriever app but this is not auto connecting and this is no longer working!
That was the last point: even the router password retriever app is acting like I didn't connect to a new router since its last analyze!
So could you help me fix this annoying bug?
For now I got an hypothesis: I got XPosed and a device ID changer app.
And it contains an useless but impossible to disable option that is "changing the SSID"
Default configuration make your phone to display your SSID. But not with the local variable where your actual SSID is displayed! No, with the SSID you got when you installed the app. So you can connect to another Wi-fi and still got the same SSID (perfectly useless)
Rest of my theory is that messing up with SSID display may cause network state not to be saved properly. But this is only a supposition. And this is hard to figure it...
So to corroborate this theory, a subquestion: What is the local Android variable where SSID is stored? Tried %WIFI, %SSID but it doesn't work. And I didn't found it after a quick search.
Thank you in advance!
Sorry for wasting your time with so much text :/

https://android.stackexchange.com/questions/124792/my-phone-stopped-remembering-wifi-passwords
There are also people conplaining this problem.
In the link pasted on the top, there is a possible fixes for some fortunate people... But actually this doesn't work for me.
-First, ro.secure.storage or ro.securestorage. thing does not exist on my device. I don't even know if it existed on my device.
-Second, there is something about /efs/ss_data, a file that also not exists on my device.
So I don't know if it's because Samsung built it differently or it has been removed. Keep checking...

After a check of my backups I saw that I got none of the file and property mentionned before.
So I'm unable to know where is the problem...

Atronid said:
After a check of my backups I saw that I got none of the file and property mentionned before.
So I'm unable to know where is the problem...
Click to expand...
Click to collapse
If you're saying that you looked in build.prop but you don't see any lines that say ro.securestorage, you can add those lines if they don't exist. Just edit build.prop and type the line in at the bottom then save build.prop and reboot the device.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

Droidriven said:
If you're saying that you looked in build.prop but you don't see any lines that say ro.securestorage, you can add those lines if they don't exist. Just edit build.prop and type the line in at the bottom then save build.prop and reboot the device.
Click to expand...
Click to collapse
This is what I did. Uneffective.
Why? Because I never got this prop before.
I checked my backups where the Wi-fi worked perfectly in case all of this would be due to the fact that this prop vanished because of a dark and random informatic process. And after checks I finally realized that I never had this prop...
Same thing for the file I mentionned before, located in /efs. I didn't lose it because I basically never got it.
So... This means that my device save Wi-fi informations by another way. And because I don't know this way, I cannot fix it...
(Device: Samsung Galaxy Core Prime SM-G361F AOG1 build.
Pre-rooted firmware, release date 23 February.
Latest Xposed Frameworks, Custom build by Wanam )

Atronid said:
This is what I did. Uneffective.
Why? Because I never got this prop before.
I checked my backups where the Wi-fi worked perfectly in case all of this would be due to the fact that this prop vanished because of a dark and random informatic process. And after checks I finally realized that I never had this prop...
Same thing for the file I mentionned before, located in /efs. I didn't lose it because I basically never got it.
So... This means that my device save Wi-fi informations by another way. And because I don't know this way, I cannot fix it...
(Device: Samsung Galaxy Core Prime SM-G361F AOG1 build.
Pre-rooted firmware, release date 23 February.
Latest Xposed Frameworks, Custom build by Wanam )
Click to expand...
Click to collapse
If you got a different router but kept the same network name and password and didn't change anything on your device, that might be the issue, your device is probably looking for your original router because the information you originally saved was saved while the other router was in use.
Try backing up your apps, app data and settings but don't backup your wifi settings or saved wifi information. Then boot to recovery and factory reset and wipe cache and dalvik/ART. Then reboot the device, when it boots to system, try connecting and signing into your network again and see if it saves it correctly.
If the backups you are talking about are nandroid backups created in TWRP, you can also try doing an advanced restore in TWRP, you can restore just the data from your previously working backup without restoring everything else.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE

Thank you, I'll try this out

Droidriven said:
Try backing up your apps, app data and settings but don't backup your wifi settings or saved wifi information. Then boot to recovery and factory reset and wipe cache and dalvik/ART. Then reboot the device, when it boots to system, try connecting and signing into your network again and see if it saves it correctly.
If the backups you are talking about are nandroid backups created in TWRP, you can also try doing an advanced restore in TWRP, you can restore just the data from your previously working backup without restoring everything else.
I DO NOT PROVIDE HELP IN PM, KEEP IT IN THE THREADS WHERE EVERYONE CAN SHARE
Click to expand...
Click to collapse
Well, tried what you told me and this didn't end well...
I used to make a factory reset of my phone. The problem was fixed. When I connected to the wifi first time, now each time I disabled and re-enabled it automatically reconnected (auto-connect is miraculous lol)
Then I flashed data back with TWRP recovery (backup by Nandroid app because I got a classical TarFork error with TWRP 2.7.0.1...)
When rebooting to Android it spammed 1M layers of various program crash message box.
Then using TWRP I reflashed this time everything I got then rebooting to Android the bootloader freezed.
I thought my phone was dead until I realized I could boot to recovery again. So I flashed an older backup and lost some data (fortunately I backed up SMS and apk).
My device is safe now, but this misadventure taught me lots of things:
-When I did a factory reset data has been erased, but system still the same and it reworked. So maybe an app is locking my Wi-fi like this. But which?
-Nandroid backup app is NOT reliable. If your device isn't clearly identified your backups are corrupt. Gotta erase all Nandroid backups I made.

Solved. Bug due to a bad TWRP backup. Made a fresh install and everything is fine now.
Thread closed.

[HELP] How to alter build.prop? Magisk Rooted

So I have my 930-F S7 systemless rooted with Magisk and with encryption.
I noticed that after rooting I wasn't able to use SmartView on my TV anymore, I've tried lots of things but eventually came to a proposed solution of editing build.prop and adding the following line to the end of it and it should work:
wlan.wfd.hdcp = disable
Click to expand...
Click to collapse
Unfortunately when trying to alter build.prop there was always an error saying it was read only, after a quick research it seems it's because it's a systemless root, so I should try doing it directly with Magisk.
Found myself to a helpful thread, that told me to put the above command line into a blank .txt and paste it into:
/sbin/.core/img/.core/post-fs-data.d
Click to expand...
Click to collapse
But it failed, I wasn't able to paste the file.
So I don't know what to do, has anyone faced this issue and can help me?

I was able to fix this issue and FINALLY be able to Smart View / Screen Mirror to other devices.
To do so I installed Didgeridoohan's MagiskHide Props Config Module. Installed a Terminal Emulator and proceeded to include the line mentioned on my previous post to build.prop.
After that, voila it was finally fixed.

Done.
The line is already present in my custom Rom. The problem is elsewhere.

CyberBeaR said:
I was able to fix this issue and FINALLY be able to Smart View / Screen Mirror to other devices.
To do so I installed Didgeridoohan's MagiskHide Props Config Module. Installed a Terminal Emulator and proceeded to include the line mentioned on my previous post to build.prop.
After that, voila it was finally fixed.
Click to expand...
Click to collapse
can please tell me the steps how did u you do tha
please
thanks.

[GUIDE] Google Pay working SIMPLY with unlock/root on Pixel 4/XL [GUIDE]

Hey guys... I've seen various methods to get Google Pay working and simply put, none of them worked for me. All that I could find left was advanced stuff involving SQLite editors and that's just not for everyone. So I started trying other known working methods from different devices, and this is what I did to get it going without issue.
1. Open Magisk, Magisk Hide, and tick the check box next to Google Pay. Proceed normally through the following steps after doing so.
2. Force stop Google Pay, clear app data/storage.
3. Open a root file manager
4. Using root file manager, find /data/data/com.google.android.gms/databases directory
5. Select a file called db.dg and chmod the permissions to 440, save and make sure it in fact saves
6. Reboot and set up Google Pay.
This should get you set up in no time without a need for modules or advanced user techniques. Hope it helps!
Edit: People seem to really dislike this method for some reason, so just throwing out there it seems everyone else recommends the SQL editing. This method worked for me, but YMMV and everyone else hates it

wrongway213 said:
Hey guys... I've seen various methods to get Google Pay working and simply put, none of them worked for me. All that I could find left was advanced stuff involving SQLite editors and that's just not for everyone. So I started trying other known working methods from different devices, and this is what I did to get it going without issue.
Unlocked users start at Step 1 below. Rooted users - First open Magisk, Magisk Hide, and tick the check box next to Google Pay. Proceed normally through the following steps after doing so.
1. Force stop Google Pay, clear app data/storage.
2. Open a root file manager OR reboot to TWRP if you don't have one
3. Using root file manager OR TWRP file manager, find /data/data/com.google.android.gms/databases directory
4. Select a file called db.dg and chmod the permissions to 440, confirm if in TWRP, save and make sure it in fact saves if using a file manager.
5. Whether in TWRP or using a root file manager. reboot and set up Google Pay.
This should get you set up in no time without a need for modules or advanced user techniques. Hope it helps!
Click to expand...
Click to collapse
That will only work if the attestation values in the dg.db file haven't been changed to flag root/unlocked bootloader already.
If your values have already been changed, you will need to manually edit the dg.db file or use the Magisk modules from this post: https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950/post79643248

ilal2ielli said:
That will only work if the attestation values in the dg.db file haven't been changed to flag root/unlocked bootloader already.
If your values have already been changed, you will need to manually edit the dg.db file or use the Magisk modules from this post: https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950/post79643248
Click to expand...
Click to collapse
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:

wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
Having TWRP or not changes nothing for anyone that makes a mistake with those edits or Magisk. Editing the dg.db and messing that up doesn't require TWRP to fix it and there's already a boot image with Magisk core only mode posted by Tulsdiver that will save you in case a Magisk module screws things up (the Google Pay fix module is working perfectly, BTW).
People probably shouldn't be messing with any of this until they understand everything that entails getting Google Pay working on a modified device. I'd argue that changing permissions of the dg.db file is just as difficult for anyone who doesn't understand what they're doing as it is going all the way and modifying the actual values in the dg.db file. It's all a slippery slope for the overzealous people anyway.

wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
Grab the modified kernel in the themes area that forces modules to be deactivated. That way you can just temp boot it to fix your issues if it goes south on you. I've used it several times so far when needing around with different combos of mods, etc...
https://forum.xda-developers.com/pixel-4-xl/themes/magisk-modules-disabler-booting-magisk-t3990557

While I appreciate your efforts this is a halfbaked hack and like the previous poster said it's will do nothing if those values have been tripped. I have always been a believer of figuring out things and going the long route that way you know why and how it was done it's very convenient for somebody else to do it and you just flash it but if you do it yourself you'll find out the intricacies of how Android and how rooting and modding works....

CyberpodS2 said:
Grab the modified kernel in the themes area that forces modules to be deactivated. That way you can just temp boot it to fix your issues if it goes south on you. I've used it several times so far when needing around with different combos of mods, etc...
https://forum.xda-developers.com/pixel-4-xl/themes/magisk-modules-disabler-booting-magisk-t3990557
Click to expand...
Click to collapse
That's kind of my reason for not wanting to use mods on this device yet - being tied to Fastboot at any given time isn't practical for me. Being unable to buy gas because my phone isn't set up isn't practical for me. My goal is to use my device just like I did when I had working TWRP on other devices without losing functionality OR having to rush to a PC for fastboot. Neither are practical solutions for me - making simple modifications that are easily overwritten gives me much less anxiety than messing with things at a deeper level.

wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
No disrespect, it looks like you're active here and helpful, but I don't think editing some values some values in a SQL editor that is tested and proven in a thread that has 55+ pages is going to hurt anything.

vanydotk said:
No disrespect, it looks like you're active here and helpful, but I don't think editing some values some values in a SQL editor that is tested and proven in a thread that has 55+ pages is going to hurt anything.
Click to expand...
Click to collapse
I'm apprehensive because of what SQL changes under the hood typically mean. I know most people haven't built ROMs, built kernels, maintained for a ROM Team, done platform development, etc. etc . - I have done all those things. One thing I learned is that there are TWO scenarios that will ALWAYS necessitate a clean flash no matter what - SQL changes and Android version changes. Given we don't know as much as we typically do about the state of Coral without TWRP due to Android 10 changes makes me unwilling to assume things proven to work on other devices will work when we get an OTA on this one. Chmod perms will be overwritten but SQLite changes can cause things to go south in my experience - none of which relating to this module. It's about SQL vs chmod for me. I'm doing what I trust and understand until recovery exists to fix things without needing a PC. If no one else finds use for it, I'm OK with that. For my use case - it makes perfect sense. :good:

Fair enough, I figured you knew what you were talking about, everyone needs to make their own decisions. Nonetheless, thanks for contributing!

Here's a simple way to get gpay to work on stock with root after you hide gms and gpay with magisk.
1. Install Termux app and open the app
2. Type pkg install sqlite hit enter and let it install.
3. Type su hit enter
4. Copy and paste this then hit enter
am force-stop /data/data/com.google.android.apps.walletnfcrel && chmod 777 /data/data/com.google.android.gms/databases/dg.db && /data/data/com.termux/files/usr/bin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';" && chmod 444 /data/data/com.google.android.gms/databases/dg.db
5. Reboot

The Magisk modules are honestly easier.
Busybox module, SQLite module, reboot, the fix module, and reboot once more.

LLStarks said:
The Magisk modules are honestly easier.
Busybox module, SQLite module, reboot, the fix module, and reboot once more.
Click to expand...
Click to collapse
How hard is it to enter a few lines in terminal? Lol
People should learn how to fix things without always relying on a module or a zip they can flash.

The manual fix isn't persistent.

LLStarks said:
The manual fix isn't persistent.
Click to expand...
Click to collapse
What I posted is.

It's weird that google pay to registry my credit cards is so unstable after flashing Gpay Sqlite fixer 1.7. When flashing Gpay sqlite fixer 1.7 at first time, I could registry my 1st credit card but it failed in next credit card. It showed up an error message and said that my phone has been rooted and .... ", So I returned commend mode to key-in few words to make me registry rest 3-credit-card successfully.

You could just delete the GMS folder while rooted and it also works
This is something myself and another user found on the p3 when Google started tripping the values on unlock
Rolling back to a previous version also works but we found that deleting that folder from /data/data along with gsf folder fixed it
Of course after clearing gpay cache.
This is working on my p4xl too

wrongway213 said:
I'm apprehensive because of what SQL changes under the hood typically mean. I know most people haven't built ROMs, built kernels, maintained for a ROM Team, done platform development, etc. etc . - I have done all those things. One thing I learned is that there are TWO scenarios that will ALWAYS necessitate a clean flash no matter what - SQL changes and Android version changes. Given we don't know as much as we typically do about the state of Coral without TWRP due to Android 10 changes makes me unwilling to assume things proven to work on other devices will work when we get an OTA on this one. Chmod perms will be overwritten but SQLite changes can cause things to go south in my experience - none of which relating to this module. It's about SQL vs chmod for me. I'm doing what I trust and understand until recovery exists to fix things without needing a PC. If no one else finds use for it, I'm OK with that. For my use case - it makes perfect sense. :good:
Click to expand...
Click to collapse
It might work for you but like it's been said multiple times, if the values are already tripped then your method is useless. Then it would REQUIRE SQL editing.
Posting an incomplete or half baked method can cause issues with newer people on these forums no matter how "simple" it may be.
spaceman860 said:
How hard is it to enter a few lines in terminal? Lol
People should learn how to fix things without always relying on a module or a zip they can flash.
Click to expand...
Click to collapse
This 100%
Sent from my Pixel 4 XL using Tapatalk

Hi there. Just a question. With this mod google pay works flawlessly all the time? No need to redo the procedure all few days when there are updates to play service? Because i need a real stable google pay when i am out only with my mobile to pay.

Just delete the folder...GMS will recreate the folder withthe right values because magisk is already setup to hide GMS

Experience & questions on Flashing unofficial lineageos17 & magisk on Doogee S68Pro

TL;DR, I'm having 'SIM not detected' issues and my laptop will crash if I open another tab, please help I've attached output of `locat -b radio`
SOURCES
https://sourceforge.net/projects/an...8-UNOFFICIAL-treble_arm64_bvS.img.xz/download
https://github.com/topjohnwu/Magisk/releases/tag/v23.0
open_gapps-arm64-10.0-nano-20211021.zip from https://opengapps.org/
https://unofficialtwrp.com/twrp-3-3-1-root-doogee-s68-pro/
PREVIOUS EXPERIENCE:
I believe about two years back I had already installed an earlier build of LineageOs v17 Magisk v19 using fastboot. This was a trial and error kind of thing as I'm only a fanatic when I have to be. After a long time I finally had a working combination; sort of. Soon about every month or so, or after a couple of restarts, my SIM card would not get detected. Though different behaviors would occur, like 'Emergency calls only', 'No Service' or SMS suddenly not coming through. Since then one time or two a restart fixed the issue until the next month or so. I tried inserting the SIM in every order of events, wiping cache/ dalvik, switching airplain mode, resetting network settings, uninstalling magisk and so on. Then I read somewhere I can't remember about draining the battery capacitors(?) by turning the device on and off on an empty battery until there's no power left and the screen doesn't light up. So I did that and that worked! After a couple of times running into this issue on a fully charged 6300mah battery I downloaded 'generic battery drainer' from the GPlayStore and that app is still on my main screen. Apparently when the device shuts down as the app is draining it, the SIM is detected again when I power up after that, so no need too drain completely... I couldn't find answers anywhere and I like Lineage so much that I just accepted it :')
RECENT EXPERIENCE:
This weekend I decided to give it another try and went for LineageOs v18 but TWRP wouldn't go any further than 'Failed to mount /system/<something>' and I finally went for the above mentioned sources. I patched TWRP recovery using the Magisk app (though I get the impression that this was designed out of necessity, I kinda like being able to switch between Magisk like this). It took me a while to understand that using wipe and decrypting data in TWRP before flashing system (fastboot) has the result of adjusting the system partition to the size of system image when flashing, leaving no space for gapps. Then I flashed stock rom, started device and let it encrypt, then flash the new system image. This kept the original system size with enough space. System started up nicely after, except for: In magisk I got "abnormal state, other su detected". After much reading I could link it to the /system/xbin/su binary. Renaming this (scared to remove) fixed that and $PATH was even appended with ":/sbin:/sbin/.magisk/busybox:". And then, the SIM card issues started after my first couple of reboots :') When it works, so far it's only when I boot without magisk.
QUESTIONS:
Whenever I use the wipe option in TWRP that will also decrypt the device, I can wipe whatever I want. But as soon as system starts it's encrypting data again and I have to use adb for example. Isn't this a generic thing? I get confused about reading so much to use TWRP for this.
Can anyone shed light on the effects of what I'm describing with "draining the battery"? And how running the drainer app might have similar effects?
What is a better approach to configure the size of the system partition? Cause now it's basically twice as big as it has to be
Is the /system/xbin/su in the Lineage build? Is that the built-in root that was/ is/ will be deprecated?
And the GOLDEN question, how can I fix these SIM issues? My head is exploding with information trying to figure out what apps and processes are involved in this. As a logcat first-timer I managed to get the output of `logcat -b radio`, see attached file. This line caught extra attention "Failed getting samsung hardware radio", but I'm out of my territory.
THANKS in advance for any input,
greetings, from a little experienced flasher

RUNNING WITH MAGISK
Further inspecting the lines of logcat -b radio, it seams that ril-daemon isn't started when I'm booting with Magisk/ root, like in the previously attached file. Also getprop shows way fewer props with 'ril' in the value than starting non-root, though altering in count between boots. Reading this https://wladimir-tm4pda.github.io/porting/telephony.html and under RIL Initialization "RIL daemon reads rild.lib path and rild.libargs system properties to determine the Vendor RIL library to use and any initialization arguments to provide to the Vendor RIL" I'm wondering, can it be something as simple as a missing PATH or env value? Anyone have the same experience?

RUNNING WITHOUT MAGISK
logcat -b radio shows way more output and many more things happening. I get the impression that the issue is in or close to the application framework layer... I'm now, still hopeful, attaching two files of logcat radio output. One after boot, up to the login screen and one after login.
Between my post and now, I did however "Remove Telephony Subsystem" through setting => Phh Treble Settings => Misc features, (just trying things out as I read stuff) and I haven't been able to get SIM working again, also not after draining the battery as previously worked. Can this be related? How do I get it back (without reflashing)?

Finally some time to update again. As I have understood, Lineageos18 seems to have an extra level of complexity with the need for mounting system as rw and gets more complex if it is encrypted, so I'm still with magisk patched twrp and GSI Lineageos17.
My SIM still isn't working while booted as root, and I can at least determine that rild is not started and also not present/ available through the terminal. As to why and how to fix that, please let me know if you do! I read some places that PATH has to be inserted with the value of PATH from the non-root env in the init.environ.rc file. That did not make a noticable difference for me. I have not installed the magisk app. So far my SIM is working better than before in non-root/ normal system boot, even after restarts and switching to and back from root.
Some (trivial) things I found many questions and few answers about so far on my quest, in case it might help someone:
I could get rid of "too many symbolic links encountered" in the twrp terminal by setting PATH to just one bin location like '/sbin'. I also had this ld.config.txt error in the terminal (which indeed did not exist on my phone) and was able to trace it back to the /system/system/bin/dlinker64 binary trying to mount that file. I just renamed that and that resolved the error. Then I was able to use the terminal to edit the init.environ.oc file (I could not get adb to work in twrp mode). Not anything specifically, but I found this (among many posts on this forum) quite helpful https://www.didgeridoohan.com/magisk/MagiskInstallationIssues.