[Samsung Galaxy Note 9 (Snapdragon) ROMs, Kernels, ] elliwigy:
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 u:object_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:
[MENTION=381438]samsung[/MENTION] - for letting us PWND them time and time again!

@chainfire - SuperSU of course
[MENTION=4470081]topjohnwu[/MENTION] - MagiskSU of course
[MENTION=4591212]me2151[/MENTION] - 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!
[MENTION=8360749]partcyborg[/MENTION] - For also spending countless hours helping answer questions in here so I don't have to hahah
[MENTION=7277512]mweinbach[/MENTION] - 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