Related
// Sorry, wrong sub-forum.
Some of you may know the new policy of Google about SD cards support since the release of ICS, but some OEMs (namely Samsung) have gone against that and continue to include an SD slot for expandable storage.
However, it seems Google have new policy too for SD cards, for security purpose KitKat does not allowed 3rd party apps to access others folder (they are only allowed to access com.3rdpartyappsname) which is a good thing but I also heard that preinstalled file manager is considered as a system apps and can access the SD (Exporitng and importing), but my Samsung Galaxy S 5 said different things, my File Manager could paste file from MicroSD to Internal Storage but my File Manager could not paste file form Internal Storage to MicroSD and also could not create new folder/file in MicroSD.
I've found SDFix apps for this problem but it required rooted device and I am not thinking to root my own device for security purpose and I am also afraid to lose "unkown" things when I am rooting my Samsung Galaxy S 5. I know there's several topics discussing about the benefits and disadvantages of rooting Android devices, but what I am looking for is, the benefits and disadvantages of rooting Samsung Galaxy S 5, specifically, for example breaking Samsung ToS, voids the warranty.
Is there anyway I could transfer the file from Internal Storage to the MicroSD card without the need of uploading it to the internet and downloading it via computer and using adapter for the MicroSD and manually transfer the file? I am not a geek computer so honestly it kinda annoying for myself because I can't using my WiFi direct to transfer file between Windows 8.1 (Laptop) to my Samsung Galaxy S 5.
As a note, there's no way for myself to transfer file to my Samsung Galaxy S 5 without remove the MicroSD card and install it to the adapter and transfer the file manually because when I am using connecting my Samsung Galaxy S 5 via usb port to the laptop, it does connect but it refused me to transfer file (to MicroSD or to Internal Storage), so there's only 2 way to transfer file to my Samsung Galaxy S5 that I know, upload it to the internet and let my Samsung Galaxy S 5 download it or using MicroSD adapter and transfer it manually, both of them are inefficient, do you know how to fix these problems?
As a second note, my File Manager seems does not have full access to the MicroSD, is that normal?
big.LITTLE said:
about the benefits and disadvantages of rooting Android devices
Click to expand...
Click to collapse
Disadvantages: only one, knox incremented so garanty void.
Advantages: million reasons to root your phone (backup, theming, total control of your S5).
For your sdcard write pb, root, xposed then xposed modules (several fixes exist now).
Best regards
Franky
fgth90 said:
Disadvantages: only one, knox incremented so garanty void.
Advantages: million reasons to root your phone (backup, theming, total control of your S5).
For your sdcard write pb, root, xposed then xposed modules (several fixes exist now).
Best regards
Franky
Click to expand...
Click to collapse
Disandvatages are two... the knox and the ota updates
Salim.Keady said:
Disandvatages are two... the knox and the ota updates
Click to expand...
Click to collapse
Right, thanks to add.
But no need OTA when flashing custom ROMs
I wouldn't say that a disadvantage is the Knox counter. I'm rooted and running Dynamic Kat and my Knox is still 0x0. I'm also on AT&T with locked bootloader though.
Is there a way to avoid the warranty void when rooting the devices?
big.LITTLE said:
Is there a way to avoid the warranty void when rooting the devices?
Click to expand...
Click to collapse
My *guess* is - Root isn't inherently the issue, but replacing the boot loader could be, as would changing any number of system apps or the kernel to an unsupported version - whichever ones KNOX are validating.
I also have a rooted G900A, am current on all OTA, and was able to get/maintain root safely via TowelRoot ( thanks to http://forum.xda-developers.com/att-galaxy-s5/general/g900and3tong3keeprootota-zip-t2862299 ). I have a number of apps frozen with Titanium Backup (as in all bloatware and almost everything Samsung), knox is not tripped, etc. *all* I would need to do to clean up behind myself would be to un-root, should I need warranty support. Should I need that I would refer to this guide ( http://forum.xda-developers.com/showpost.php?p=53454972&postcount=1 )
Cheers.
As long as rooted properly, and status of the phone is official there is no issue.
Although some root apps will change the status to custom. Simple solution there too. Install Xposed framework and Wanam module, and change the status to Official. Done and dusted.
fgth90 said:
Right, thanks to add.
But no need OTA when flashing custom ROMs
Click to expand...
Click to collapse
You are right... however people with poor download speed consider this ...
big.LITTLE said:
Is there a way to avoid the warranty void when rooting the devices?
Click to expand...
Click to collapse
No. They patched the exploit
---------- Post added at 03:45 PM ---------- Previous post was at 03:43 PM ----------
C0derbear said:
My *guess* is - Root isn't inherently the issue, but replacing the boot loader could be, as would changing any number of system apps or the kernel to an unsupported version - whichever ones KNOX are validating.
I also have a rooted G900A, am current on all OTA, and was able to get/maintain root safely via TowelRoot ( thanks to http://forum.xda-developers.com/att-galaxy-s5/general/g900and3tong3keeprootota-zip-t2862299 ). I have a number of apps frozen with Titanium Backup (as in all bloatware and almost everything Samsung), knox is not tripped, etc. *all* I would need to do to clean up behind myself would be to un-root, should I need warranty support. Should I need that I would refer to this guide ( http://forum.xda-developers.com/showpost.php?p=53454972&postcount=1 )
Cheers.
Click to expand...
Click to collapse
The reason Knox isn't tripped by towelroot is because it is an exploit. It is an unintended effect. Running any other root method even if it only installs the su binary still trips Knox.
So I got around to "rooting" my "LG G4" (H525) via that one click tool called Kingroot.
So far so fine.
Pretty much all applications that require root will will allow it...
Except for one:
FlashFire....
It keeps telling me that root access was not possible,
that I shall't install SuperSU.
[However SuperSU will error out right on the start telling me to `update the binary']
=> What binary ? Why update it (just got the newest SuperSU from the Playstore)?
Trying to flash said binary using any Flashify merly showed me the lovely "your device is bricked" bugdroid...
Any idead from someone with similar FlashFire / SuperSU problems ?
Thanks in advance:
-Rye-
Do you have a custom recovery/twrp?
Sent from my HTC One M9 using Tapatalk
Nope, all stock.
(Part of the reason why this confuses me so much... I changed nothing... except for Root)
KingRoot is intentionally designed to serve two purposes. The first is to give you root access through their app. The second, which they don't warn you about, is to prevent you from managing that root access any other way than through their app.
They have written their app specifically to force you to use their root manager and to prevent you from uninstalling it and installing any other SU app. They went so far as to specifically block installation of SuperSU because they're upset that it replaces their app (which is blatantly absurd and hypocritical). If that's acceptable to you, then certainly do it their way.
However, because they place such restriction on root access (which seems to be a self-contradictory philosophy) then it directly interferes with the installation of more powerful root apps like flashing utilities and Xposed itself.
At this point there are two options. Either you can find a utility that breaks their stranglehold on your device and follow the specific instructions to remove their app and install something that's not restrictive, or you can restore your device to pre-root condition and root it again yourself using the open, non-restrictive methods made available to the community. Each method may be about as complicated as the other.
THIS IS CURRENTLY NOT WORKING
A newer version is available here: https://forum.xda-developers.com/apps/supersu/suhide-lite-t3653855
suhide is an experimental (and officially unsupported) mod for SuperSU that can selectively hide root (the su binary and package name) from other applications.
Pros
- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.10.07)
Cons
- Ultimately a losing game (see the next few posts)
- No GUI (at the moment) - Unofficial GUI by loserskater
Requirements
- SuperSU v2.78 SR1 or newer (link)
- SuperSU installed in systemless mode
- Android 6.0 or newer
- TWRP (3.0.2 or newer, with access to /data - link!) or FlashFire (link)
Xposed
Xposed is not currently officially supported, but if you want to use it directly, you must be using @topjohnwu 's systemless xposed v86.2 exactly (attached at the bottom). It seems to mostly work during my non-extensive testing, but there are still some performance issues (both boot-time and run-time). Proceed with caution, expect bootloop.
Alternatively, there are some reports that the latest Magisk version + the latest systemless xposed (for Magisk) also works. I have not personally tested this.
CyanogenMod
I've personally tested with CM13 on i9300 without issue, however, several users are reporting it doesn't work for them. Proceed with caution, expect bootloop. Also, aside from just flashing SuperSU, you need to make sure /system/bin/su and /system/xbin/su are removed, or CM's internal root will still be used.
Usage
Install/Upgrade
- Make sure you have the latest SuperSU version flashed in systemless mode
- Make sure you are using the latest TWRP or FlashFire version
- Remove any and all Xposed versions
- If you have been having issues, flash suhide-rm-vX.YY.zip first, and note that your blacklist has been lost.
- Flash the attached suhide-vX.YY.zip
- If you are upgrading from suhide v0.16 or older, reflash SuperSU ZIP, and note that your blacklist has been lost.
- Optionally, flash the Xposed version linked above, and pray
At first install SafetyNet is automatically blacklisted.
If you have just flashed a ROM, it is advised to let it fully boot at least once before installing suhide.
Uninstall
- Flash the attached suhide-rm-vX.YY.zip. The version may appear older, the uninstall script doesn't change very often.
Blacklisting an app
You need the UID (10000 to 99999, usually 10xxx) of the app, which can be tricky to find, or the process name. There may be a GUI for this at some point.
(Note that all commands below need to be executed from a root shell)
If you know the package name, ls -nld /data/data/packagename will show the UID - usually the 3rd column.
Similarly, for running apps, ps -n | grep packagename will also show the UID - usually the 1st column.
Note that the process name is often the same as the package name, but this is not always the case. UID is more reliable for identifying a specific app, and it is also faster than blocking based on process names.
When you know the UID or process name:
Add to blacklist: /su/suhide/add UID or /su/suhide/add processname
Remove from blacklist: /su/suhide/rm UID or /su/suhide/rm processname
List blacklist: /su/suhide/list
All running processes for that UID or process name need to be killed/restarted for su binary hiding. For SuperSU GUI hiding, the device needs to be restarted. I recommend just (soft-)rebooting your device after making any changes.
Please keep in mind that many apps store their rooted state, so you may need to clear their data (and then reboot).
Integration into SuperSU
This mod isn't stable, and probably will never be (see the next few posts). As SuperSU does aim to be stable, I don't think they're a good match. But who knows, it all depends on how things progress on the detection side.
Detections
This mod hides the su binary pretty well, and does a basic job of hiding the SuperSU GUI. The hiding is never perfect, and suhide itself is not undetectable either. This will never be a perfectly working solution.
Debugging bootloops
- Get your device in a booting state
- Make sure you have TWRP or a similar recovery
- Install LiveBoot (link)
- If you are not a LiveBoot Pro user, enable the Freeload option
- Enable the Save logs option
- Recreate the bootloop
- In TWRP, get /cache/liveboot.log , and ZIP+attach it to a post here.
Download
Attached below.
Any rm version should work to uninstall any suhide version.
There may be multiple versions of suhide attached, please look carefully which one you are downloading!
YOU ARE EXPLICITLY NOT ALLOWED TO REDISTRIBUTE THESE FILES
(pre-v0.51: 17410 downloads)
Hiding root: a losing game - rant du jour
Most apps that detect root fall into the payment, banking/investing, corporate security, or (anit cheating) gaming category.
While a lot of apps have their custom root detection routines, with the introduction of SafetyNet the situation for power users has become worse, as developers of those apps can now use a single API to check if the device is not obviously compromised.
SafetyNet is of course developed by Google, which means they can do some tricks that others may not be able to easily do, as they have better platform access and control. In its current incarnation, ultimately the detection routines still run as an unprivileged user and do not yet use information from expected-to-be-secure components such as the bootloader or TPM. In other words, even though they have slightly more access than a 3rd party app, they still have less access than a root app does.
Following from this is that as long as there is someone who is willing to put in the time and effort - and this can become very complex and time consuming very quickly - and SafetyNet keeps their detection routines in the same class, there will in theory always be a way to beat these detections.
While reading that may initially make some of you rejoice, this is in truth a bad thing. As an Android security engineer in Google's employ has stated, they need to "make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model".
The problem is that with a rooted device, it is ultimately not possible to guarantee said security model with the current class of SafetyNet tamper detection routines. The cat and mouse game currently being played out - SafetyNet detecting root, someone bypassing it, SafetyNet detecting it again, repeat - only serves to emphasize this point. The more we push this, the more obvious this becomes to all players involved, and the quicker SafetyNet (and similar solutions) will grow beyond their current limitations.
Ultimately, information will be provided and verified by bootloaders/TrustZone/SecureBoot/TIMA/TEE/TPM etc. (Samsung is already doing this with their KNOX/TIMA solutions). Parts of the device we cannot easily reach or patch, and thus there will come a time when these detection bypasses may no longer viable. This will happen regardless of our efforts, as you can be sure malware authors are working on this as well. What we power-users do may well influence the time-frame, however. If a bypass attains critical mass, it will be patched quickly.
More security requires more locking down. Ultimately these security features are about money - unbelievably large amounts of money. This while our precious unlocked bootloaders and root solutions are more of a developer and enthusiast thing. While we're all generally fond of shaking our fists at the likes of Google, Samsung, HTC, etc, it should be noted that there are people in all these companies actively lobbying to keep unlocked/unlockable devices available for us to play with, with the only limitation being that some financial/corporate stuff may not work if we play too hard.
It would be much easier (and safer from their perspective) for all these parties to simply plug that hole and fully lock down the platform (beyond 3rd party apps using only the normal APIs). Bypassing root checks en masse is nothing less than poking the bear.
Nevertheless, users want to hide their roots (so do malware authors...) and at least this implementation of suhide is a simple one. I still think it's a bad idea to do it. Then again, I think it's a bad idea to do anything financial related on Android smartphone that isn't completely clean, but that's just me.
Note that I have intentionally left out any debate on whether SafetyNet/AndroidPay/etc need to be this perfectly secure (most people do their banking on virus ridden Windows installations after all), who should get to decide which risk is worth taking, or even if Google and cohorts would be able to design the systems more robustly so the main app processor would not need to be trusted at all. (the latter could be done for Android Pay, but wouldn't necessarily solve anything for Random Banking App). While those are very interesting discussion points, ultimately it is Google who decides how they want this system to work, regardless of our opinions on the matter - and they want to secure it.
--- reserved ---
Changelogs
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
As always thank you Chainfire! I will try and edit this post.
Edit @Chainfire this seems to work for enabling Android Pay! I didn't get the chance to actually pay yet. But it did let me add my card and did not display the message about a failed authorization of Android check! Before I couldn't even get past that first screen.
Edit 2: @Chainfire It seems to of had an adverse effect on Snapchat. I cleared cache on the app, uninstalled and reinstalled and restarted. It kept Force closing after a photo no matter what. I used suhide-rm and it seems to have fixed the app from any issues. Thanks again and hopefully we'll get you some more reports. Either way your solution works!
Tested on stock rooted 7.0 Nexus 6p.
@Chainfire
What was your reason for doing this project?
Sent from my Nexus 6P using XDA-Developers mobile app
Ofthecats said:
What was your reason for doing this project?
Click to expand...
Click to collapse
For building it, curious if the method I came up with would work well. For releasing, if others are doing it, join them or be left behind.
I'm assuming with custom ROM android pay still won't work right?
HamsterHam said:
I'm assuming with custom ROM android pay still won't work right?
Click to expand...
Click to collapse
I'd just give it a try. It's spoofing the specific app, not the entire ROM that matters. It's fairly simple to try.
Installed on LG G4 w/ V20g-EUR-XX update and rerooted with TWRP 3.0.2-0 and SuperSU-v2.76-2016063161323. seems to be working fine, for the moment. Thank you for the update.
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
djide said:
So far so good, I was able to add card to android pay. I would try using it during lunch and report back. Again, thanks for the continuous hard work.
Click to expand...
Click to collapse
What was the UID or process you found to blacklist it with?
Sent from my ONEPLUS A3000 using Tapatalk
how to install it? which file should I flash ? Both?
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Joshmccullough said:
What was the UID or process you found to blacklist it with?
Click to expand...
Click to collapse
Android Pay comes blacklisted out-of-the-box
HamsterHam said:
I can't see to add an app using terminal.
I'm typing in
/data/adb/suhide-add 10284
Says file not found. Can someone help, cheers.
Click to expand...
Click to collapse
Are you in Android or TWRP ?
ls -l /data/adb/
Chainfire said:
Android Pay comes blacklisted out-of-the-box
Click to expand...
Click to collapse
Derp. That's what I get for not reading the entire sentence under 'Install' in the OP......thanks!
PedroM.CostaAndrade said:
how to install it? which file should I flash ? Both?
Click to expand...
Click to collapse
Please don't quote a large post like that just to ask a single question.
Please read the first post, so you know what to do.
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
thdervenis said:
OnePlus 2 here, stock 6.0.1, systemless rooted with SuperSU Pro v2.76, flahed using Flashfire.
Passes SafetyNet check, does not pass my bank's root check, propably for the reasons the OP states above.
Click to expand...
Click to collapse
You need to blacklist the UID for your bank. Directions are in the OP.
Samsung Xposed Safe Mode script v1.0
What does it do?
This is an init.d script which emulates the xposed safe mode where you can press any button during boot, get a vibrate (to know it detected you), and it will disable all your xposed modules. To be used in case of bootloops because of incompatible modules.
This only disables all modules so that you can boot. It does NOT actually uninstall or disable xposed itself.
Why would I need this?
I talked with the developer of xposed for Samsung, wanam, and apparently, xposed safe mode was disabled for Samsung devices due to a Knox issue (if you disabled xposed, Knox will hate you and refuse to boot the phone). This is good, but if you have a bootloop, AND you're on a bootloader locked device, you have NO CHOICE but to wipe your data. Ouch!! That's a heavy penalty for accidentally installing one malfunctioning module!
Or maybe your phone still is bootloader unlocked, but you're running Samsung xposed and safemode is still disabled for you. Then you'd rather have xposed safemode back just for the ease of not having to go through recovery to fix things.
How does it work?
1. Press any of three buttons during boot (volume keys, or home button). You have 10 seconds from bootup to choose to do this.
2. System will give you 2 short vibrates to tell you it detected it.
3. Press any button 4 more times, each time will give you another short vibration.
4. One long vibration will signal to you that xposed has been disabled.
5. The script will automatically reboot your device in 6 seconds. This is because we can't disable xposed, so xposed will STILL load modules on this bootup, which means you'll still see the bootloop momentarily until you reboot.
Great! How do I install it?
This is an init.d script, so you need init.d support in your phone. Obviously, if you have a bootlocked device, you probably don't have init.d support. This is not a guide on how to get init.d support, but I'll offer you a few tips you can use to search yourself.
- install-recovery.sh, since it's called by init.rc during boot, can be hijacked in order to create an init.d system.
- If install-recovery didn't work, SuperSU also includes an su.d directory which is executed at a similar time. Just throw a script in there, or throw a script in there which enables use of the init.d folder (run-parts /system/etc/init.d).
Anyways, here's how you install it:
- Place the script you downloaded into
Code:
/system/etc/init.d
OR
Code:
/system/su.d
Give the script proper permissions for the folder it's in
- For su.d folder, it is root:root 0700 (rwx------)
- For init.d folder, it could be a variety of permissions. My init.d folder runs as a result of su.d, so I gave it same permissions as su.d. If yours doesn't, then you might want to try root:root 0755 (rwxr-xr-x)
- The important point here is to make sure it's at least root user and group, readable and executable, rwxr-xr-x
Will it work on my device?
It should work on any device really, if you follow the simple instructions. But I've only tested it on the ATT S4 (Lollipop 5.0.1), so I can't guarantee it will work on your device. Test it out and see if it works for you! It probably will!
You saved me!
I'm glad to hear that! I love to hear and see a thanks, so make sure to click the thanks button and maybe write a post too!
Bugs and problems
You know how to report bugs and issues. State all relevant information related to the problem; device, problem in clear detail, with reproducible steps, and anything else you might need.
Related custom xposed builds
Here are a list of Samsung custom xposed builds I know this "safe mode problem" to be present in. (Don't forget, this problem is likely to be in any and all Samsung xposed custom builds due to the nature of the Knox problem).
[UNOFFICIAL] Xposed for Samsung Lollipop by arter97
[UNOFFICIAL][5.0][v87.1][03 Dec] Xposed for Samsung Lollipop 5.0.x
[UNOFFICIAL][5.1/6][v87.1][28 Nov]Xposed for Samsung Lollipop/Marshmallow
Disclaimer: As usual, while I've made every attempt to make it perfect, there are no guarantee it will work for you. By using this, you agree not to hold me accountable in case something bad happens to you (or it didn't save your device)! Do your own testing to make sure it works before you actually need to use it in an emergency!
FAQ
It didn't vibrate
You probably have a different device which places the vibrator in a different location. I don't have your device, so maybe you'll need to help me debug and find where the vibrator is located at.
It didn't work!
What happened? Give me some detailed information about exactly what you did, what happened, and the device you're on!
Some possible problems to investigate are:
Does the script have correct user: owner and permissions?
Is your init.d or su.d system even working? Make sure it is first
Nice work!
It should help with incompatible modules leading to a bootloop, but it won't prevent Xposed from loading, the flag "/data/data/de.robv.android.xposed.installer/conf/disabled" is ignored on my Xposed version, done here for a reason, i got many bootloop reports in the past by people accidentally triggering safe mode by physical buttons, leading to Knox refusing to deal with modified binaries.
Fortunately it does not seem to be the same with TouchWiz 7.0, so i will bring it back later for Nougat.
wanam said:
Nice work!
It should help with incompatible modules leading to a bootloop, but it won't prevent Xposed from loading, the flag "/data/data/de.robv.android.xposed.installer/conf/disabled" is ignored on my Xposed version, done here for a reason, i got many bootloop reports in the past by people accidentally triggering safe mode by physical buttons, leading to Knox refusing to deal with modified binaries.
Fortunately it does not seem to be the same with TouchWiz 7.0, so i will bring it back later for Nougat.
Click to expand...
Click to collapse
Thank you!
It certainly will help a lot for disabling incompatible modules. Yes, although it doesn't technically disable xposed itself. It's really great that future versions aren't that way!
I actually thought of creating another script which utilizes back and menu key buttons to actually uninstall xposed from backups (an actual disable xposed script of sorts), but I thought it was too much.
Unreal.... can a group of professionals get together and spend a day cracking the bootloader and root the Verizon version note 5 not even one custom rom for this device all other models have gotten there attention we need to crack this note 5 please
so far no one can hack n920v bootloader. Me also waiting for this info. Until now my n920v still not root yet. huhuu
It does not bypass bootloader
It's funny, in the UART logs running an engineering s-boot, it will say that an invalid image was detected, and it will reboot to avoid tripping Knox. A t-mobile phone I got, I accidentally flashed a Verizon image, and there went Knox, before I had intended to. Verizon has probably drastically reduced the unexplained returns, with the lies suggested on here to use by doing that. That might be a main motivation to consider.
But back to the subject, before I ever tried attempted to understand Magisk (which I used on my XT1575), which sort of does the same thing I did, but still allows selinux, was to use the engineering kernel, and did the following:
& Mount /system as loopback in /data/systemmirror
& Mount a loop back image over /system, which effectively hides it
& Link to each file in the loopback to the mirror, except for what I didn't want, and add what I did want. I even got xposed, microg/unifiednlp working like that. I didn't want to use supersu, but I imagine it can be done too. Some files had to be on the loopback system because uh I think it didn't like dynamic linking some library files that were links, that was fun to debug again and again and again until it worked.
& Set selinux permissive, because links aren't normally allowed, and I couldn't figure out how to make that work in the policy, and I could have reloaded it with the tools in the supersu apk if I knew what I was doing.
Thus, a tethered root is made. Tethered. Every boot up, you have to log in with adb to run the shell script that mounts everything, changes selinux, and kills system_server, effectively rebooting it. I could not figure out another way. It worked, minus samsung pay.
While that doesn't sound so bad, I went into the subway, was playing my hacked up version of shattered pixel dungeon, and the kernel crashed. Man, I that was a bummer. Still haven't rooted it properly.
If there's a fwbl1 or something that breaks the chain of trust from a developers SDK, sboot could be modified to load any binary without tripping Knox into an existing sboot probably.
I've removed so much stuff from this post so many times while preparing the draft to submit to my comment editor, I wonder how many times before I'm forced to decide whether a sign post visible in 1/9th of a picture is part of a street sign or not.