!!!Possible Perm Root Within Reach!!! 4-5-2019 - Alcatel Idol 5 Guides, News, & Discussion

!!!Possible Perm Root Within Reach!!! 4-5-2019 - Alcatel Idol 5 Guides, News, & Discussion

I would like to share some info I have garnered from various forms of testing and such. I know a guy with a newer alcatel brazilian only model running android 6. We have been trying to get into the phone for a while. mtk-su was the way in to begin with. since it's a newer phone, it has decent security. system somehow gets mounted to zram so any changes made to system get erased at boot. System is ro and can't be changed perm as of yet. A script was created that basically spams mount system rw, which allows a few second gaps of system being rw, long enough to push some supersu files and start the daemon. Now, pushing strictly supersu files and then opening supersu will get the update binary request, which does not complete, and canceling the update still doesnt allow the installed su binary to work, so no temp root. Basically supersu is a no go. Now fast forward ahead a bit of time., and this is what the process is looking like.
Use mtk-su to grant ADB shell temp root
run the script for system rw from that temp root adb shell
squeeze the supersu files minus su to their locations using the small system rw gaps and also rename mtk-su to su and push that where it goes
give those pushed files correct permissions
start the su daemon
Temporary Paydirt!!
you now have temp root on a ro system, locked bootloader, all security in place. You are bypassing the need for supersu all together as you have temp root that doesnt ask for permission. any app that wants root gets it automatically.
that makes a guy wonder what flashfire would do, could you flash proper supersu that way and have it be systemless?
can you run selinux switch and have selinux be permissive
on a non zram system setup, could you gain perm root by not having system reloaded every time
could you somehow get to and mount the real system(location of real system is known: mblck25 or something) on a zram system setup and then gain perm root
Anyways, this is just something that's been banging around in my head, slowly spilling out, with small strides being made. Alot of testing still needs to be done, the process tweaked and refined and alot of sleepless nights i'm sure. Any thoughts, opinions, ideas, help is surely welcomed and needed. Once i have a dedicated tester on board and exhaust all possibilities and get the process to a good point, i'll release what I have. Until then, rest assured that I am doing what i can, for a phone i don;t own. The good thing is that this will potentially work on any device that mtk-su works on, which at this point is turning out to be a very decent amount of MTK devices

Mount /$y$tem a$ -rw
What i$ the $cript?

Related

New Root Security Model?

I saw in the SDK this permission for apps to request:
public static final String FACTORY_TEST
Run as a manufacturer test application, running as the root user. Only available when the device is running in manufacturer test mode.
Constant Value: "android.permission.FACTORY_TEST"
Click to expand...
Click to collapse
Our current model with superuser whitelist is not very secure because a malicious person could bundle their own su binary and circumvent the restrictions. It would seem that having our custom roms run in test mode would provide a great solution: using Android's own permission/security model for apps to run as root. This should force all apps to visibly request root permissions at install time.

I am in favor of anything that will improve the security of my phone. It concerns me that anyone who knows what they are doing can so easily boot into recovery mode on my phone, wipe and flash any ROM they want. Granted, they would not have access to my information if the wipe and flash. But, it makes it trivially simple to hijack my phone. I would like to have some password protection for Recovery and Fastboot.

i am by no means a dev, but it seems to me that this probably just has to do with the adp devices

what's a adp device? and explain how they could possibly do this again?

android developer phone.

jaaronmoody said:
i am by no means a dev, but it seems to me that this probably just has to do with the adp devices
Click to expand...
Click to collapse
well, technically, if we have root, dont have an "ADP" device?
when I do a fresh install, it says welcome to Android Developer Phone 1 (in most ROMs)

the adp device was a specific phone release for developers to be used with the sdk.

jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
I know that, but the hardware is the same as ours (they just get the awesome battery cover)

jaaronmoody said:
the adp device was a specific phone release for developers to be used with the sdk.
Click to expand...
Click to collapse
Most roms especially cyanogen Roms are based on SDK/ADP1 directly and thus making our devices recognizable as ADP Devices.

Simple solution could be to restore the original su binary at boot.
1) keep a copy in the boot image ramdisk
2) scan the path at boot for su
3) compare md5sum with the original
4) delete if md5sum is different
5) restore original trusted su
and also just for paranoia:
6) scan system for setuid binaries and report to the user

This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.

lbcoder said:
This has NOTHING to do with ADP1. Test mode is just that... TEST MODE, i.e. diagnostics and repair. Probably needs to be plugged into a test station that authenticates using some manufacturer diagnostic keys. I really doubt that it would be a simple matter of requesting root permissions as this would be too easy to abuse.
And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
Thanks for clearing that up.
The idea posted earlier about recovery menu password should be lofted at Cyanogen (or anyone willing to take that on). Should we make a thread for it?

Keep in mind that it is physically impossible to secure your phone against somebody who gets their hands on the actual device. You can only make it harder to get at it. If somebody wanted to they could just read the flash chip directly or use JTAG to get at it. However, I agree that adb could be made a bit more secure.

And to the OP: No, you can't just bundle an 'su' binary and run it. The binary has to be owned and setuid as root in order for it to actually get root permissions. There is nothing magical about the su binary -- it is just 'sh' renamed as 'su', chown'd as root, and chmod 4755. A regular user can NOT chown root. Only root can chown root. Note that the su binary that works with the root app is modified such that it will terminate if the root app doesn't grant root permission. For all these reasons, su+rootapp is fairly secure. Not against someone unauthorized getting their hands on the device, but against some malevolent app taking root and running amok.
Click to expand...
Click to collapse
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.

nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how

nobodyimportant said:
@lbcoder,
That's nonsense. Check any linux system, /bin/sh is always owned by root and is always executable. Running an executable owned by user X does NOT run said program as X. Copying a binary onto the phone preserves permissions, so if i chowned an sh binary as root on my computer and copied it over, the binary will stay owned by root. The su binary is just that, a binary. It is not simply a shell owned by root.
Click to expand...
Click to collapse
I have one thing to say to you:
http://en.wikipedia.org/wiki/Setuid
Now that you've made a complete and utter fool of yourself, how do you feel?
FYI: your regular user can NOT chown root. Go ahead and try it.

alapapa said:
you're missing the bit (pun intended) about su being setuid root. when a normal user runs su, it does, indeed run as root, but it uses the security subsystem behind the scenes to prevent unauthorized activity:
http://en.wikipedia.org/wiki/Setuid
the 'unzip' executable will, indeed, preserve ownership, but to my knowledge, there's no way to copy a setuid binary to the phone as a normal user -- there may be a way it could be pulled off, but I don't know how
Click to expand...
Click to collapse
It is a moot point whether the setuid bit can be restored since a regular user doesn't have the ability to change the owner to anything but self, which means that the best they could do is create an su binary that will give other users THEIR OWN permissions.
A regular user can change ownership *only* to self -- i.e. if they have group or other write permission, then they can chown the file. They can also change the group, but only to groups to which they are members -- and this requires that they already have some form of write permission on the file.
Note that extracting a file is no different than actually *creating* the file, which means that if the user couldn't simply MAKE the file, then they can't *extract* the file either.
If any of this was untrue, there would be nothing to stop any user from doing something like this to take over any Linux computer (except from within a chroot jail, but that doesn't apply here);
cp `which sh` ~/su; chown root:root ~/su; chmod 4755 ~/su
** but that most definitely won't work.

Help with SELinux - rooting a new device

Evening all,
I have a Vivo V3 Max (www.vivoglobal.com) which runs Android 5.0.1 (no Marshmallow ROM yet!). It has never been able to be rooted and I am on a mission to do it.
The progress I've made so far is as follows:
1. Got a custom TWRP recovery image flashed and working on the phone so I can boot into recovery. This recovery has full root access to everything.
2. Modified the boot image so that ADB runs as root (insecure mode). This allows me to have a full root shell via ADB when the phone has fully booted as normal. Also modified the fstab to make /system world writable.
3. Installed various "recovery flashable ZIPs" to no avail - it puts all the files (su in /system/xbin etc) in the right place but still no root access.
4. Manually created the required files and symlinks myself, which resulted in the same as 3) above.
I am now at the stage where I realise that it's SELinux not allowing the full root to go through in normal userspace. I can run setenforce 0 (and also su 0 setenforce 0) via ADB to make SELinux permissive, but still I get "/system/bin/sh: su: Operation not permitted" when running SU from a Terminal Emulator app.
Is there anyone out there who can help me with the SELinux side of things to allow /system/xbin/su to run? Also tried systemless with Magisk but same result. Vivo do not release kernel sources for any of their products so I'm stuck with what I have. I do at least have read/write access to all partitions on the device though, so if theres any modifications I can make then I'm happy to try them. I have a full NAND backup of the entire thing.
I have tried using supolicy etc to inject rules, but I'm not really sure what I should be injecting.
Any seasoned developers willing to help me out? My background is in PHP, C#, VB.NET and Windows Servers but I'm OK with Linux too.
Many thanks!

I have attached the output on supolicy --dumpav in case it is useful.

Just a quick update on this... I managed to find a ROM for a very similar device hardware-wise, which was pre rooted. After tweaking the boot image to allow it to run on my device, I could see that /system/xbin/su still had no permission to run. This was despite the fact that the security policies from the other device was copied directly to mine, and on that other device full root access is possible using the exact same ROM that I ported.
I am therefore left with the conclusion that it doesn't matter how many rules I inject to sepolicy or how many domains I modify, the kernel is the limiting factor here. Since Vivo do not release the kernel sources for any of their devices I guess I'm screwed. Would this be against the GPL and is something I can take up with Vivo? I'm gutted...

[ROOT][SamPWND][N960U][WIP-Combo Needed]

Hello XDA!
Samsung has been semi SamPWND again!
Disclaimer:
This root method was developed and tested on the N960U model. This is the only model I have that is a Samsung device. I do have friends and other devs however that have tested this method on various other Samsung devices on both Qualcomm and Exynos chipsets and it has worked on a good number of them meaning this method is not limited to the Note 9. With that being said, due to all the time I have already spent on this and not having any other devices, I will ONLY be supporting the N960U. So do not get upset if I do not respond to you if you have a Samsung A8934839K312 on 7.1 Android (aka a device I have never even heard of before.)
Disclaimer 2:
This root method is mainly for dev's or those who like to tinker and figure things out. The reason I say this is because at this time, you are REQUIRED to be on a factory/combination firmware to mess with the root method. I will ignore any comments/questions for people who do not read this disclaimer and ask me how to root stock etc. as that is what I have been trying to do for over a month now. If you need your phone for work or a daily then I suggest only messing with this root method if you have a lot of spare time since it involves flashing combo firmware at which mobile services and other stuff will not be functional. You have been warned!
Disclaimer 3:
This thread/poc are essentially to get you the ability to use root apps and have a root shell, that is it. If I have time and see some questions that are legit questions I will try to provide help in a timely manner. This POC simply pushes busybox binary from Magisk.zip and SuperSU (the last version chains released before retirement) and installs it in sbin/daemon mode. There is also a way to install MagiskSU in daemon mode as well as ways to install root to /system/xbin for example and do mods such as Xposed that typically need to modify the system partition but that is not the purpose of this thread and these methods are a bit more involved (require modifying the root script as well as setting up bind mounts and other stuff.) Hopefully once this is released and some devs chime in I hope there will eventually be others contributing with various root scripts, install methods etc. and of course HOPEFULLY find a way to write to system/odm/vendor partitions so we can eventually run root on stock!
Disclaimer 4:
I am NOT responsible if you break your phone, wipe your IMEI, hard brick etc. etc.! Also, I spent months to get to this point and already had someone steal my files from AFH (I know, my fault for not hiding them) so please do not take my work as your own. If you want to use it in any way/shape/form just ask for permission and/or give credits in your thread is all I ask! If you are however using someone else's modified files and in here trying to get help I might turn you away (back to the person who provided the modified files) just an FYI!
I think that is enough disclaimers for now!
Note: This thread will most likely be ugly for a bit as I am terrible with making these things look pretty... Hopefully as time goes I will keep improving it or find someone who is trustworthy I can make a "contributor" so they can fix it up for me haha.
Now, Let's Get To It!
Technical Details:
This is sort of a spawn from an exploit I found and reported to Samsung back on the Tab S3 that I never released on XDA. That method (long story short) involved modifying the Persist partition and flashing it in ODIN as ODIN did not check it for integrity. Of course it was patched by Samsung who gave me some $$$ and gave me a shout out on their security bulletin which was pretty cool!
This method is similar to "Persist Root" except we are not flashing any modified partitions in ODIN. Instead, on many Samsung combination firmwares there is an init rc script on /system. If you want to know if your device is compatible a good starting point would be to look for a file called "init.lab.rc" which is typically located at "/system/etc/init/init.lab.rc" like so:
-rw-r--r-- 1 root root ubject_r:system_file:s0 14784 2008-12-31 10:00 init.lab.rc
As it stands, we cannot edit this script. I noticed something cool however when I was reading it one day. Specifically one thing that caught my eye was this:
chmod 777 /data/lab/run_lab_app.sh
There are MANY files and scripts at /data/lab. Luckily, the init.lab.rc sets permissions to "0777" and sets ownership to system on the entire /data/lab directory! If you are still with me, this means all the contents of this directory are world readable/writeable and we can modify any of the files in this DIR without elevated privileges!
Now I am showing the "run_lab_app.sh" script specifically for a reason. We know we can modify any scripts on /data/lab, but how can we execute it with elevates privileges? Going back to the init.lab.rc, if you scroll to the bottom of the rc file you will see this:
service start_abc /system/bin/sh /data/lab/run_lab_app.sh factory abc+
user system
group system
disabled
oneshot
on property:sec.lab.abc.start=1
start start_abc
setprop sec.lab.abc.start 0
Now what that means is, when you set the property "sec.lab.abc.start" to "1" it executes the abc service as system user and more specifically it will start by executing the "run_lab_app.sh" script! Therefore, after you modify the script to your liking, push it to /data/lab/run_lab_app.sh, then do a "setprop sec.lab.abc.start 1" your script will be executed as system user!
Now system obviously is not "root". Now that we can execute as system user we have more attack vectors to elevate privileges even more. Ideally, I remembered how I rooted the Tab S3 about a year ago using Persist partition. As it stands, we are not able to read/write on persist. If we were to set permissions however on /persist using the run_lab_app.sh script, then we can gain access to it! Therefore, one would only need to add this command to the run_lab_app.sh script and execute it using the setprop command:
chmod -R 0777 /persist
As soon as you modify the script, push it and execute the setprop command, it will change permissions on the /persist DIR to be world readable/writeable!
Now, the reason why I like to use Persist, there is a script that is executed by INIT on every reboot automatically (this means it is executed by root!) The script in question is this one "/persist/coresight/qdss.agent.sh." (I am not sure if this script itself is a Qualcomm specific script or not.) Modifying this script has no ill effects on anything from what I have seen.
Now to see how the script is executed you can look in "/vendor/etc/init/hw/init.qcom.test.rc" and you will see some interesting stuff including this:
crownqltesq:/vendor/etc/init/hw # cat init.qcom.test.rc | grep persist
service cs-early-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh early-boot /vendor/bin/init.qcom.debug.sh
service cs-post-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh post-boot /vendor/bin/init.qcom.debug.sh
write /persist/coresight/enable 1
write /persist/coresight/enable 0
crownqltesq:/vendor/etc/init/hw #
As I stated earlier, due to this init script, the qdss.agent.sh script is executed by init context/root user automatically during early boot and post boot. This means once you get everything set up, you won't need to keep reinstalling root (unless you mess something up) on each reboot. This is ideal since we don't have a way yet to modify system/vendor/odm partitions yet. Think of it as a "systemless" root.
For the POC I have provided in this thread for example, it contains the bare minimum SU files. The files in the attached zip are simple: SamPWND.bat, sampwnd1.sh, sampwnd2.sh, /sampwnd which contains su, sukernel, supolicy, libsupol.so and busybox. The way it works is this:
1) You double click the .bat file and it should do everything for you! The .bat file will:
- Push sampwnd1.sh to /data/lab/run_lab_app.sh
- Execute the lab script by doing "setprop sec.lab.abc.start 1"
- Push sampwnd2.sh to /persist/coresight/qdss.agent.sh
- Push root files in "sampwnd" folder to /persist/coresight/sampwnd
- Set permissions on the files we just pushed to Persist to 0777
- Reboot the device (Note: The .bat file reboots the device at this point since everything is in place to root when the device reboots, it's that simple!)
After the device reboots, you should now be able to use a root shell as well as sideloading any root apps will work (apps such as TiBu, Root Explorer, Flashfire etc. etc.)
When the device reboots, the qdss.agent.sh script does the following automatically:
1) Mounts rootfs and sets permissions to 0777 so we can access /sbin
2) Pushes the contents of the root files folder "sampwnd" to /sbin
3) Sets permissions to the files we just moved to /sbin
4) Exports the LIB path to /sbin due to the libsupol.so being needed to patch the sepolicy with supolicy
- The export command is "export LD_LIBRARY_PATH=/sbin"
- Once the script is over and you use another app or go into a shell etc. the LIB path will be gone/reset so you don't need to
worry.
5) Patches the sepolicy for SU
6) Installs SU by executing "su --install"
7) Executes the SU daemon by running "su --daemon"
8) Lastly, remounts rootfs back to RO.
As stated earlier, these commands are all automatically executed by init/root each time you reboot the device. Essentially, whatever we put into the qdss.agent.sh script will be executed on boot by init/root. If for some reason permissions are lost, we should still have our lab script and we would only need to run "setprop sec.lab.abc.start 1" to change permissions on persist again!
The initial files I provide today are just a simple root install script. I have successfully used the root script to install MagiskSU, Xposed (using bind mounts to overlay on /system) and other tests. I also at one point made a backup script that backed up all the partitions on the device into a folder which I extracted to my PC for safe keeping, you get the picture! Once you have root however, you can do these things easier as you will have root access.
Now that you know the workings of the exploit (err exploits?) I will explain briefly what is needed and how to test it.
Pre-requisites:
1) Download links will be in 2nd post.
2) For the purpose of this thread and the only device I personally have, you should have a N960U/U1/W on a rev1 bootloader (there isn't a rev2 BL yet so most should be good to go.)
3) A vulnerable Combo Firmware. I linked the one I use in Post 2. I use 1ARG4 Factory/Combo firmware. Of course you will need ODIN to flash the combo.
4) The root files/7z linked in post 2.
5) Stock firmware for when you are done playing, testing, etc. etc.
6) Almost forgot, you will need ADB. I will not go into details on this, if you don't have a working ADB Google is your friend. I recommend setting it to your path so you can use ADB from anywhere on the PC.
Install Instructions:
1) Extract the root files 7z into a DIR of your choice.
2) Flash whichever vulnerable combo firmware you are using via ODIN.
3) Once it boots up, make sure your device is seen by adb by running "adb devices"
4) Double click the .bat file.
5) That's it! Your device will reboot and you should be rooted!
If for some reason it is not working and you are on a N960U/U1/W, there could be a number of reasons. If you are not using the 1ARG4 combo I linked then it's possible the combo you are using is not vulnerable. It could also be an issue with ADB. Sometimes if things get crazy throughout your testing you might need to reflash /persist in ODIN or reflash the combo firmware in ODIN then re-run the .bat file (I only experience this typically when I get crazy with the root script and end up losing permissions to everything or something I added in the root script is causing the device to boot-loop etc. etc.)
Now donations are not required but feel free to throw me some beer money if you want! My paypal email/link is in a few places, you shouldn't have any trouble finding it!
TELEGRAM GROUP IS COMING REAL SOON!
We will use the TGRAM to provide support, ideas, share scripts/files and HOPEFULLY, we can all figure out together how to turn this into rooting the stock firmware as this is the goal and will be the primary focus of the chat!
Credits:
@samsung - for letting us PWND them time and time again!
@chainfire - SuperSU of course
@topjohnwu - MagiskSU of course
@me2151 - For all the time and help he is going to be putting in with us! Such a great guy! lol
@jrkruse - For everything! Everything from EDL support, ROM support, Root support you name it!
@partcyborg - For also spending countless hours helping answer questions in here so I don't have to hahah
@mweinbach - He writes great articles for XDA! He is a good kid who gets his hands on cool things frequently
@"mysecretfriendfromfaraway - I will not name him haha, he knows who he is. He always helps out and gets great things!
XDA:DevDB Information
SamPWND N960U Root, Tool/Utility for the Samsung Galaxy Note 9
Contributors
elliwigy
Version Information
Status: Testing
Created 2019-05-05
Last Updated 2019-05-05

[ROOT][SamPWND][N960U][WIP-Combo Needed]

Hello XDA!
Samsung has been semi SamPWND again!
Disclaimer:
This root method was developed and tested on the N960U model. This is the only model I have that is a Samsung device. I do have friends and other devs however that have tested this method on various other Samsung devices on both Qualcomm and Exynos chipsets and it has worked on a good number of them meaning this method is not limited to the Note 9. With that being said, due to all the time I have already spent on this and not having any other devices, I will ONLY be supporting the N960U. So do not get upset if I do not respond to you if you have a Samsung A8934839K312 on 7.1 Android (aka a device I have never even heard of before.)
Disclaimer 2:
This root method is mainly for dev's or those who like to tinker and figure things out. The reason I say this is because at this time, you are REQUIRED to be on a factory/combination firmware to mess with the root method. I will ignore any comments/questions for people who do not read this disclaimer and ask me how to root stock etc. as that is what I have been trying to do for over a month now. If you need your phone for work or a daily then I suggest only messing with this root method if you have a lot of spare time since it involves flashing combo firmware at which mobile services and other stuff will not be functional. You have been warned!
Disclaimer 3:
This thread/poc are essentially to get you the ability to use root apps and have a root shell, that is it. If I have time and see some questions that are legit questions I will try to provide help in a timely manner. This POC simply pushes busybox binary from Magisk.zip and SuperSU (the last version chains released before retirement) and installs it in sbin/daemon mode. There is also a way to install MagiskSU in daemon mode as well as ways to install root to /system/xbin for example and do mods such as Xposed that typically need to modify the system partition but that is not the purpose of this thread and these methods are a bit more involved (require modifying the root script as well as setting up bind mounts and other stuff.) Hopefully once this is released and some devs chime in I hope there will eventually be others contributing with various root scripts, install methods etc. and of course HOPEFULLY find a way to write to system/odm/vendor partitions so we can eventually run root on stock!
Disclaimer 4:
I am NOT responsible if you break your phone, wipe your IMEI, hard brick etc. etc.! Also, I spent months to get to this point and already had someone steal my files from AFH (I know, my fault for not hiding them) so please do not take my work as your own. If you want to use it in any way/shape/form just ask for permission and/or give credits in your thread is all I ask! If you are however using someone else's modified files and in here trying to get help I might turn you away (back to the person who provided the modified files) just an FYI!
I think that is enough disclaimers for now!
Note: This thread will most likely be ugly for a bit as I am terrible with making these things look pretty... Hopefully as time goes I will keep improving it or find someone who is trustworthy I can make a "contributor" so they can fix it up for me haha.
Now, Let's Get To It!
Technical Details:
This is sort of a spawn from an exploit I found and reported to Samsung back on the Tab S3 that I never released on XDA. That method (long story short) involved modifying the Persist partition and flashing it in ODIN as ODIN did not check it for integrity. Of course it was patched by Samsung who gave me some $$$ and gave me a shout out on their security bulletin which was pretty cool!
This method is similar to "Persist Root" except we are not flashing any modified partitions in ODIN. Instead, on many Samsung combination firmwares there is an init rc script on /system. If you want to know if your device is compatible a good starting point would be to look for a file called "init.lab.rc" which is typically located at "/system/etc/init/init.lab.rc" like so:
-rw-r--r-- 1 root root ubject_r:system_file:s0 14784 2008-12-31 10:00 init.lab.rc
As it stands, we cannot edit this script. I noticed something cool however when I was reading it one day. Specifically one thing that caught my eye was this:
chmod 777 /data/lab/run_lab_app.sh
There are MANY files and scripts at /data/lab. Luckily, the init.lab.rc sets permissions to "0777" and sets ownership to system on the entire /data/lab directory! If you are still with me, this means all the contents of this directory are world readable/writeable and we can modify any of the files in this DIR without elevated privileges!
Now I am showing the "run_lab_app.sh" script specifically for a reason. We know we can modify any scripts on /data/lab, but how can we execute it with elevates privileges? Going back to the init.lab.rc, if you scroll to the bottom of the rc file you will see this:
service start_abc /system/bin/sh /data/lab/run_lab_app.sh factory abc+
user system
group system
disabled
oneshot
on property:sec.lab.abc.start=1
start start_abc
setprop sec.lab.abc.start 0
Now what that means is, when you set the property "sec.lab.abc.start" to "1" it executes the abc service as system user and more specifically it will start by executing the "run_lab_app.sh" script! Therefore, after you modify the script to your liking, push it to /data/lab/run_lab_app.sh, then do a "setprop sec.lab.abc.start 1" your script will be executed as system user!
Now system obviously is not "root". Now that we can execute as system user we have more attack vectors to elevate privileges even more. Ideally, I remembered how I rooted the Tab S3 about a year ago using Persist partition. As it stands, we are not able to read/write on persist. If we were to set permissions however on /persist using the run_lab_app.sh script, then we can gain access to it! Therefore, one would only need to add this command to the run_lab_app.sh script and execute it using the setprop command:
chmod -R 0777 /persist
As soon as you modify the script, push it and execute the setprop command, it will change permissions on the /persist DIR to be world readable/writeable!
Now, the reason why I like to use Persist, there is a script that is executed by INIT on every reboot automatically (this means it is executed by root!) The script in question is this one "/persist/coresight/qdss.agent.sh." (I am not sure if this script itself is a Qualcomm specific script or not.) Modifying this script has no ill effects on anything from what I have seen.
Now to see how the script is executed you can look in "/vendor/etc/init/hw/init.qcom.test.rc" and you will see some interesting stuff including this:
crownqltesq:/vendor/etc/init/hw # cat init.qcom.test.rc | grep persist
service cs-early-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh early-boot /vendor/bin/init.qcom.debug.sh
service cs-post-boot /vendor/bin/sh /persist/coresight/qdss.agent.sh post-boot /vendor/bin/init.qcom.debug.sh
write /persist/coresight/enable 1
write /persist/coresight/enable 0
crownqltesq:/vendor/etc/init/hw #
As I stated earlier, due to this init script, the qdss.agent.sh script is executed by init context/root user automatically during early boot and post boot. This means once you get everything set up, you won't need to keep reinstalling root (unless you mess something up) on each reboot. This is ideal since we don't have a way yet to modify system/vendor/odm partitions yet. Think of it as a "systemless" root.
For the POC I have provided in this thread for example, it contains the bare minimum SU files. The files in the attached zip are simple: SamPWND.bat, sampwnd1.sh, sampwnd2.sh, /sampwnd which contains su, sukernel, supolicy, libsupol.so and busybox. The way it works is this:
1) You double click the .bat file and it should do everything for you! The .bat file will:
- Push sampwnd1.sh to /data/lab/run_lab_app.sh
- Execute the lab script by doing "setprop sec.lab.abc.start 1"
- Push sampwnd2.sh to /persist/coresight/qdss.agent.sh
- Push root files in "sampwnd" folder to /persist/coresight/sampwnd
- Set permissions on the files we just pushed to Persist to 0777
- Reboot the device (Note: The .bat file reboots the device at this point since everything is in place to root when the device reboots, it's that simple!)
After the device reboots, you should now be able to use a root shell as well as sideloading any root apps will work (apps such as TiBu, Root Explorer, Flashfire etc. etc.)
When the device reboots, the qdss.agent.sh script does the following automatically:
1) Mounts rootfs and sets permissions to 0777 so we can access /sbin
2) Pushes the contents of the root files folder "sampwnd" to /sbin
3) Sets permissions to the files we just moved to /sbin
4) Exports the LIB path to /sbin due to the libsupol.so being needed to patch the sepolicy with supolicy
- The export command is "export LD_LIBRARY_PATH=/sbin"
- Once the script is over and you use another app or go into a shell etc. the LIB path will be gone/reset so you don't need to
worry.
5) Patches the sepolicy for SU
6) Installs SU by executing "su --install"
7) Executes the SU daemon by running "su --daemon"
8) Lastly, remounts rootfs back to RO.
As stated earlier, these commands are all automatically executed by init/root each time you reboot the device. Essentially, whatever we put into the qdss.agent.sh script will be executed on boot by init/root. If for some reason permissions are lost, we should still have our lab script and we would only need to run "setprop sec.lab.abc.start 1" to change permissions on persist again!
The initial files I provide today are just a simple root install script. I have successfully used the root script to install MagiskSU, Xposed (using bind mounts to overlay on /system) and other tests. I also at one point made a backup script that backed up all the partitions on the device into a folder which I extracted to my PC for safe keeping, you get the picture! Once you have root however, you can do these things easier as you will have root access.
Now that you know the workings of the exploit (err exploits?) I will explain briefly what is needed and how to test it.
Pre-requisites:
1) Download links will be in 2nd post.
2) For the purpose of this thread and the only device I personally have, you should have a N960U/U1/W on a rev1 bootloader (there isn't a rev2 BL yet so most should be good to go.)
3) A vulnerable Combo Firmware. I linked the one I use in Post 2. I use 1ARG4 Factory/Combo firmware. Of course you will need ODIN to flash the combo.
4) The root files/7z linked in post 2.
5) Stock firmware for when you are done playing, testing, etc. etc.
6) Almost forgot, you will need ADB. I will not go into details on this, if you don't have a working ADB Google is your friend. I recommend setting it to your path so you can use ADB from anywhere on the PC.
Install Instructions:
1) Extract the root files 7z into a DIR of your choice.
2) Flash whichever vulnerable combo firmware you are using via ODIN.
3) Once it boots up, make sure your device is seen by adb by running "adb devices"
4) Double click the .bat file.
5) That's it! Your device will reboot and you should be rooted!
If for some reason it is not working and you are on a N960U/U1/W, there could be a number of reasons. If you are not using the 1ARG4 combo I linked then it's possible the combo you are using is not vulnerable. It could also be an issue with ADB. Sometimes if things get crazy throughout your testing you might need to reflash /persist in ODIN or reflash the combo firmware in ODIN then re-run the .bat file (I only experience this typically when I get crazy with the root script and end up losing permissions to everything or something I added in the root script is causing the device to boot-loop etc. etc.)
Now donations are not required but feel free to throw me some beer money if you want! My paypal email/link is in a few places, you shouldn't have any trouble finding it!
TELEGRAM LINK
https://t.me/joinchat/DxwvAlhtzHjg4EI9973BGQ
We will use the TGRAM to provide support, ideas, share scripts/files and HOPEFULLY, we can all figure out together how to turn this into rooting the stock firmware as this is the goal and will be the primary focus of the chat!
Credits:
@samsung - for letting us PWND them time and time again!
@chainfire - SuperSU of course
@topjohnwu - MagiskSU of course
@me2151 - For all the time and help he is going to be putting in with us! Such a great guy! lol
@jrkruse - For everything! Everything from EDL support, ROM support, Root support you name it!
@partcyborg - For also spending countless hours helping answer questions in here so I don't have to hahah
@mweinbach - He writes great articles for XDA! He is a good kid who gets his hands on cool things frequently
@"mysecretfriendfromfaraway - I will not name him haha, he knows who he is. He always helps out and gets great things!
XDA:DevDB Information
SamPWND N960U Root, Tool/Utility for the Samsung Galaxy Note 9
Contributors
elliwigy
Version Information
Status: Testing
Created 2019-05-05
Last Updated 2019-05-05

Downloads:
1) 1ARG4 Factory/Combo Firmware
MD5: bf0702b4e85ac1547b5706bb4859f554
2) Root Files
MD5: 342f15e13c72f3d0f9194d8a14058ac9

Mine also...

Nice job!

Thank you @elliwigy !!!
Your determined effort is soooooooooooooooo much appreciated. :good:

You are the man! This has got to be the first out. I dont think i have seen anything else. As usual you have done something remarkable for Samsung and this time the Note 9 of all. I wish there was the ability to get root on U5 for the S8/S8+ with SamPWND. Have you researched any more into that lately?

noidodroid said:
You are the man! This has got to be the first out. I dont think i have seen anything else. As usual you have done something remarkable for Samsung and this time the Note 9 of all. I wish there was the ability to get root on U5 for the S8/S8+ with SamPWND. Have you researched any more into that lately?
Click to expand...
Click to collapse
not possible.. sampwnd used rev1 eng firmware lol. it was done soon as they incremented the bootloader

elliwigy said:
not possible.. sampwnd used rev1 eng firmware lol. it was done soon as they incremented the bootloader
Click to expand...
Click to collapse
Yup. =] I don't know though. Always something new that pops out of Sammys goodie bag and lands in someones lap and crawls its away onto XDA. Like you I have a silentguywhospeaksanotherlanguage that always seems to amaze me... the past 14 years. Would be awesome. Could be something kewl. Time will tell.

Definitely going to test out and report back! Sent you some money for some beers lol :highfive:

still no ones tried? lol i thought ppl would b all over it haha

elliwigy said:
still no ones tried? lol i thought ppl would b all over it haha
Click to expand...
Click to collapse
Im gonna try it when i get off work

Incredible!! Wow this alone is awesome, and that word doesn't justify it. The talent you all have for this is really impressive. Thanks to all who had a major role in this alone. I will be posting results as soon as i can, hopefully tonight. Its all possible!!
Thank You

noidodroid said:
You are the man! This has got to be the first out. I dont think i have seen anything else. As usual you have done something remarkable for Samsung and this time the Note 9 of all. I wish there was the ability to get root on U5 for the S8/S8+ with SamPWND. Have you researched any more into that lately?
Click to expand...
Click to collapse
Im PRETTY sure samfail works via edl rom from @jrkruse

Trying to install right now... So for the Combo Firmware, I am on BUild N960USQS1CSD1 . How do i find the Combo firmware for that ? is that just finding the stock firmware ?

Yeteneğiniz hayranlık uyandırdı bende. Takdir ediyorum. Tebrik ediyorum sizi.
Cihazımı test ederken yapmam gerekenleri şu şekilde sıralayabilirmiyiz kısaca?
1) 1ARG4 Factory/Combo Firmware
Odin ile telefonuma flash yapmalıyım.
2) Flashlama işlemi bittikten sonra cihazımın açılmasını beklemeliyim.
3) Cihazım açıldıktan sonra Root dosyasını cihazıma Pc üzerinden anlattığınız şekilde uygulamalıyım.
4) Root işlemi cihazımı yeniden başlattıktan sonra stok yazılım yüklemeliyim.
5) Mutlu Son.
---------------------‐---------------------------------------------
Your talent has aroused admiration. I appreciate. I congratulate you.
When I test my device, can I sort the things I need to do in the following way?
1) 1ARG4 Factory / Combo Firmware
I need to do a flash with Odin on my phone.
2) After flashing, I have to wait until my device is turned on.
3) After opening my device, I need to apply the root file to my device in the same way as I told it on PC.
4) After the root process reboot my device, I need to install the stock software.
5) Happy End

Raz12 said:
Trying to install right now... So for the Combo Firmware, I am on BUild N960USQS1CSD1 . How do i find the Combo firmware for that ? is that just finding the stock firmware ?
Click to expand...
Click to collapse
will be easiest to just use the combo linked in second post.. newrr combos r most likely patched.. also, if csd1 is pie then there will never be a pie combo so ull need to flash an oreo combo either way

axioneer said:
Yeteneğiniz hayranlık uyandırdı bende. Takdir ediyorum. Tebrik ediyorum sizi.
Cihazımı test ederken yapmam gerekenleri şu şekilde sıralayabilirmiyiz kısaca?
1) 1ARG4 Factory/Combo Firmware
Odin ile telefonuma flash yapmalıyım.
2) Flashlama işlemi bittikten sonra cihazımın açılmasını beklemeliyim.
3) Cihazım açıldıktan sonra Root dosyasını cihazıma Pc üzerinden anlattığınız şekilde uygulamalıyım.
4) Root işlemi cihazımı yeniden başlattıktan sonra stok yazılım yüklemeliyim.
5) Mutlu Son.
---------------------‐---------------------------------------------
Your talent has aroused admiration. I appreciate. I congratulate you.
When I test my device, can I sort the things I need to do in the following way?
1) 1ARG4 Factory / Combo Firmware
I need to do a flash with Odin on my phone.
2) After flashing, I have to wait until my device is turned on.
3) After opening my device, I need to apply the root file to my device in the same way as I told it on PC.
4) After the root process reboot my device, I need to install the stock software.
5) Happy End
Click to expand...
Click to collapse
read the op. id say its pretty easy/clear..
also, it is not possible to have root on stock firmware right now, this was also clear in op.
the root only works on combo firmware.. if u need to use ur phone then i suggest not using this root method until we figure out how to make it work on stock

elliwigy said:
will be easiest to just use the combo linked in second post.. newrr combos r most likely patched.. also, if csd1 is pie then there will never be a pie combo so ull need to flash an oreo combo either way
Click to expand...
Click to collapse
Yikes, i see the difference now. I mean it's done but it's not like a normal android it seems. I see what you mean. Well I guess ill just go back to stock pie. Good work though man, you are doing great ! Just to see though, It went to a factory binary screen then to this lime green and showing all this info. That's it right ?

I hope this leads to root for normal u1 firmware. ??????

Raz12 said:
Yikes, i see the difference now. I mean it's done but it's not like a normal android it seems. I see what you mean. Well I guess ill just go back to stock pie. Good work though man, you are doing great ! Just to see though, It went to a factory binary screen then to this lime green and showing all this info. That's it right ?
Click to expand...
Click to collapse
it was prolly green due to battery being low.. it changes the color once it dips below a certain %
and yea, i assume uve never been on a combo firmware before lol they are all like that

Database Info

welcome