[GUIDE] Enable init.d support on the stock kernel - ROOT REQUIRED - Galaxy Note 3 General

Hey guys,
just got my device to run scripts put into /etc/init.d at startup and wanted to share my method with you.
First you need a script-tool from here on xda: http://forum.xda-developers.com/showthread.php?t=2055508
Thats actually doin all the magic so give the creator some credit - but just running it on your freshly rooted N3 might have some bad results. (you might lose root, at least partially - ill explain why)
So the su on the SELinux enabled devices like our note 3 has to be run as a daemon to work correctly. This is achieved by starting it through install-recovery.sh in /etc/. The init.d enable script (as far as I can tell by looking at the source) would just overwrite your install-recovery.sh and break root, plus in its "pure" form it doesnt work on the n3.
You can avoid these problems and make it actually work by editing your install-recovery.sh before running the script.
Its important you do this step before you apply the script, because it detects if the install-recovery.sh already has the required line and then does not overwrite if it finds it.
Ok here it goes - add the following line (preferably before the "/system/etc/install-recovery-2.sh" call:
Code:
/system/xbin/su -c /system/bin/sysinit system
This calls the /system/sysinit file (which is created by the script in the next step) as system user and a) prevents the overwrite of install-recovery.sh and b) makes it work by calling it as system user - without this addition by just calling /system/bin/sysinit the scripts would not run, or at least not with the required rights.
After you edited your install-recovery.sh you can run the script. (as root obviously)
Reboot and look into /data/log/ for init.d-log.txt or smth. If its there the scripts run, if not report back.
(when it didnt work on my phone at first I tried chaning the paths of the 99test script which is also created inside the init.d folder by the script, so that it would put the files on the sd card instead - to see if it was a writing permission problem or something, but it didnt help so i tried to run it trough "su system" and then it did - but I havent tried chaning back the 99test - so im not sure if this actually creates the init.d-log.txt inside the /data/log folder or if there are still permission problems... but at least the scripts do run hehe)

Related

[MOD][APK+SCRIPT+ZIP] Enable Init.d for Any Phones w/o Need of Custom Kernels!!!

** NOT Android 4.3 compatible!!! Term-init is recommended for now!!!
**Note...this is only for those who do not have init.d support...if you are using custom kernels (cyanogen mod original kernel etc.) that already supports init.d, you shouldn't run this......but if you accidentally ran this, it is ok...won't mess up anything...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
v1.0
init.d support through an app!!!​
What is init.d:
the_scotsman (Moderator Liaison Admin / Moderator Committee / XDA News Writer) said:
Init.d plays an important role in the world of Android development and customization It allows users to install scripts and mods to be run at boot—everything from battery tweaks to performance tweaks. It essentially opens the door to a world of mods only possible through the Init.d process, which in turn is usually only available on custom kernels.
Click to expand...
Click to collapse
But how?
Concept:
I have recently learnt some linux scripting and was searching for a method to enable init.d scripts support for my phone which has a stock kernel. Inspired by this thread by iridaki, I finally managed to get init.d working in my phone!!! However, I thought of the other users who still do not have a proper custom recovery...how are they gonna flash zip packages? And if it has to be done manually, it requires a lot of typing, changing file permissions etc....a very tedious process...
Therefore, I've decided to come up with a script to automate this process!!! *Drum rolls*...lol
BUT now, with the aid of Androguide.fr (creator of Pimp My ROM), we managed to integrate the script into an app to save the hassle of typing commands in terminal emulator! With just a button click, the commands will be carried out! With just a button click, the app will verify whether is there init.d support or not!
Do I have init.d support?:
Well, here is a way to test:
1. Download the file from here: View attachment 1612958
2. Extract the file, you will get a file named 00test. DO NOT flash!
3. Paste it into /etc/init.d. If there is no init.d folder, most probably you DO NOT have init.d support. However, if you still wanna try, just create the folder named "init.d"
4. Change the permissions of the init.d folder and 00test into rwxrwxrwx.
5. Reboot.
6. If you see a file named Test.log in /data, you have init.d support. If not, you will have to run Uni-init, Term-init or Zip-init.
Features:
- Utilises install-recovery.sh (if your kernel supports that, but of course, but most do...) to enable init.d scripts (busybox run-parts required)
- Will add lines in install-recovery.sh if it already exists (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing (shows time of execution), another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysinit in /system/bin, will add the required lines if it already exists
- Deletes duplicate files and lines to ensure the least of errors
Requirements:
- a rooted phone of course...
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: Link and please reboot after installing before running this script......use "normal install" method, don't use "smart install"...
Instructions:
1. Download the apk.
2. Install the apk like any normal app.
3. Launch the app.
4. The rest are pretty self-explanatory...
5. You can uninstall the app after that...
Screenshots:
**To check whether init.d is really working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have a WORKING init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
Uni-init v1.0.apk
Credits:
Thanks to:
Androguide.fr for the android app base!
Donators (big thank you! ):
@bigknowz
Feel free to posts questions below...I will try my best to help......By the way, those who used the app and found that it works, please leave a post here, stating you phone model, android version and ROM...thanks! but don't just leave comnents saying 'it doesn't work' etc...give more details if possible...
Please don't mirror / modify my work, ask for permissions first...​
**UPDATE: v3 is out now! Android 4.3 compatible!
**Term-init is also used in Droid Manager!!!**
**Featured in the XDA News Portal: Init.d Support for Any Rooted Phone (Thanks to the_scotsman!)
Hi guys...as stated in the title above, I have created a script to be ran in terminal emulator so that it will enable the support of init.d scripts!!!
**Note...this is only for those who do not have init.d support...if you are using custom kernels (cyanogen mod original kernel etc.) that already supports init.d, you shouldn't run this......but if you accidentally ran this, it is ok...won't mess up anything...
init.d support through terminal emulator!!!​
What is init.d:
the_scotsman (Moderator Liaison Admin / Moderator Committee / XDA News Writer) said:
Init.d plays an important role in the world of Android development and customization It allows users to install scripts and mods to be run at boot—everything from battery tweaks to performance tweaks. It essentially opens the door to a world of mods only possible through the Init.d process, which in turn is usually only available on custom kernels.
Click to expand...
Click to collapse
But how?
Concept:
I have recently learnt some linux scripting and was searching for a method to enable init.d scripts support for my phone which has a stock kernel. Inspired by this thread by iridaki, I finally managed to get init.d working in my phone!!! However, I thought of the other users who still do not have a proper custom recovery...how are they gonna flash zip packages? And if it has to be done manually, it requires a lot of typing, changing file permissions etc....a very tedious process...
Therefore, I've decided to come up with a script to automate this process!!! *Drum rolls*...lol
Do I have init.d support?:
Well, here is a way to test:
1. Download the file from here: View attachment test_initd.zip
2. Extract the file, you will get a file named 00test. DO NOT flash!
3. Paste it into /etc/init.d. If there is no init.d folder, most probably you DO NOT have init.d support. However, if you still wanna try, just create the folder named "init.d"
4. Change the permissions of the init.d folder and 00test into rwxrwxrwx.
5. Reboot.
6. If you see a file named Test.log in /data, you have init.d support. If not, you will have to run Uni-init, Term-init or Zip-init.
Features:
- Auto checks for required files [v2]
- Utilises install-recovery.sh (if your kernel supports that, but of course, but most do...) to enable init.d scripts (busybox run-parts required)
- Will move install-recovery.sh to install-recovery-2.sh if it already exists and call it from the main install-recovery.sh (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't [v3]
- If Superuser is using install-recovery.sh, will use install-recovery-2.sh instead [v3]
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing (shows time of execution [v2]), another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysinit in /system/bin, will add the required lines if it already exists. This is for utilising a similar method to enabling init.d in AOSP ROMs
Requirements:
- a rooted phone of course...
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: Link and please reboot after installing before running this script......use "normal install" method, don't use "smart install"...
- terminal emulator such as this: Link
Instructions:
1. Download the file.
2. Place it in the root of your sdcard directory.
3. Launch terminal emulator.
4. Type: su
5. Grant SuperUser access if prompted
6. Type: sh /sdcard/term-init.sh
7. The script will run and follow the instructions! As simple as that...
**To check whether init.d is working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
term-init.sh v3
Feel free to posts questions below...I will try my best to help......By the way, those who used my script and found that it works, please leave a post here, stating you phone model, android version and ROM...thanks! but don't just leave comnents saying 'it doesn't work' etc...give more details and screenshots if possible...
Please don't mirror / modify my work, ask for permissions first...
Source code & changelog: https://github.com/Ryuinferno/Term-init​
** NOT Android 4.3 compatible!!! Term-init is recommended for now!!!
**Note...this is only for those who do not have init.d support...if you are using custom kernels (cyanogen mod original kernel etc.) that already supports init.d, you shouldn't run this......but if you accidentally ran this, it is ok...won't mess up anything...
As Term-init does not work for certain people, I have came up with a CWM flashable zip:
init.d support through CWM!!! ​
What is init.d:
the_scotsman (Moderator Liaison Admin / Moderator Committee / XDA News Writer) said:
Init.d plays an important role in the world of Android development and customization It allows users to install scripts and mods to be run at boot—everything from battery tweaks to performance tweaks. It essentially opens the door to a world of mods only possible through the Init.d process, which in turn is usually only available on custom kernels.
Click to expand...
Click to collapse
Do I have init.d support?:
Well, here is a way to test:
1. Download the file from here: test_initd.zip
2. Extract the file, you will get a file named 00test. DO NOT flash!
3. Paste it into /etc/init.d. If there is no init.d folder, most probably you DO NOT have init.d support. However, if you still wanna try, just create the folder named "init.d"
4. Change the permissions of the init.d folder and 00test into rwxrwxrwx.
5. Reboot.
6. If you see a file named Test.log in /data, you have init.d support. If not, you will have to run Uni-init, Term-init or Zip-init.
Features:
- Utilises install-recovery.sh (if your kernel supports that, but of course, but most do...) to enable init.d scripts (busybox run-parts required)
- Will add lines in install-recovery.sh if it already exists (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing, another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysinit in /system/bin, will add the required lines if it already exists
- Deletes duplicate files and lines to ensure the least of errors
Requirements:
- a rooted phone of course...
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: Link and please reboot after installing before running this script......use "normal install" method, don't use "smart install"...
- a working CWM custom recovery
Instructions:
1. Download the file.
2. Flash zip-init.zip thorough CWM.
3. Reboot and you are done!
**If you get a status 0 error in CWM, please replace the update-binary in zip-init.zip with a working update-binary of your phone (just extract it from any CWM zip meant for your phone)...
**To check whether init.d is working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
zip-init.zip v2
Feel free to posts questions below...I will try my best to help......By the way, those who used my mod and found that it works, please leave a post here, stating you phone model, android version and ROM...thanks! but don't just leave comnents saying 'it doesn't work' etc...give more details and screenshots if possible...
Please don't mirror / modify my work, ask for permissions first...​
Troubleshooting
Troubleshooting:
**CWM might warn something about disable recovery flash when using this mod, it is just a false positive, please DO NOT select yes or else it won't work anymore**
If you have already applied the script but there is no /data/Test.log, please refer the steps below:
1. Check whether have you installed busybox properly, especially run-parts. REBOOT after installing, then only apply this script.
2. If you are using the busybox installer by Stericson, please use "normal installation method", NOT "smart installation method".
3. Check whether are these files present with the correct permissions (please change if the permissions are wrong):
- /system/bin/sysint (rwxr-xr-x) [owner: root (0), group: shell (2000)]
- /system/etc/init.d (rwxrwxrwx) [owner: root (0), group: root (0)]
- /system/etc/init.d/00test (rwxrwxrwx) [owner: root (0), group: root (0)]
-/system/etc/init.d/08setperm (rwxrwxrwx) [owner: root (0), group: root (0)]
- /system/etc/install-recovery.sh (rwxr-xr-x) [owner: root (0), group: root (0)]
- /system/etc/install-recovery-2.sh (rwxr-xr-x) [owner: root (0), group: root (0)] (may or may not be present)
4. Check whether you have run-parts installed. Go to /system/xbin, you should be able to find a fine named "run-parts"
5. Check whether you have these lines in /system/etc/install-recovery.sh (if not, please add them in manually (using Root Explorer or keep the EOL in Unix format...Google about it), remember to leave an EMPTY line at the end of the file)
Code:
# init.d support
busybox run-parts /system/etc/init.d/
6. If all the above are still not helping, please download this: run-parts.zip and extract it (DO NOT flash it). Place the file named "run-parts" in /system/xbin. Change permissions to rwxrwxrwx, owner to root (o) and group to shell (2000). Reboot and check /data again.
7. Still fails? Check your /init.rc for any lines containing "install-recovery"...if there are none, this method won't work...so use the Script Manager method.
8. Use this as a last resort: Download Script Manager from Play Store: Link. Then navigate to /etc/install-recovery.sh, select it and run as root and at boot (select the skull and gear icon).
9. If all the above are not working, and the "install-recovery" line is present, then please paste the contents of your /etc/install-recovery.sh and /etc/install-recovery-2.sh if present somewhere (like http://pastebin.com and after applying the mod of course) here for me to debug. Take a screenshot of the output after running Term-init and post here, along with your ROM version, android version and name of device.
ace 5830i stock rom
Ryuinferno said:
Hi guys...as stated in the title above, I have created a script to be ran in terminal emulator so that it will enable the support of init.d scripts!!!
Term-init --> init.d support through terminal emulator!!!
But how?
Concept:
I have recently learnt some linux scripting and was searching for a method to enable init.d scripts support for my phone which has a stock kernel. Inspired by this thread by iridaki, I finally managed to get init.d working in my phone!!! However, I thought of the other users who still do not have a proper custom recovery...how are they gonna flash zip packages? And if it has to be done manually, it requires a lot of typing, changing file permissions etc....a very tedious process...
Therefore, I've decided to come up with a script to automate this process!!! *Drum rolls*...lol
Features:
- Utilises install-recovery.sh to enable init.d scripts (busybox run-parts required)
- Will add lines in install-recovery.sh if it already exists (will not replace install-recovery.sh because certain apps such as Link2SD requires that to work), creates it if it doesn't
- Creates the init.d folder with correct permissions
- Adds 2 init.d scripts: one for testing, another to ensure that the scripts in init.d folder always have the correct permissions
- Adds sysint in /system/bin, will add the required lines if it already exists
- Deletes duplicate files and lines to ensure the least of errors
Requirements:
- busybox with required applets (especially run-parts), if not sure what is this, just install this by Stericson: BusyBox
- terminal emulator such as this
Instructions:
1. Download the file.
2. Place it in the root of your sdcard directory.
3. Launch terminal emulator.
4. Type: su
5. Grant SuperUser access if prompted
6. Type: sh /sdcard/term-init.sh
7. The script will run and follow the instructions! As simple as that...
Example:
**To check whether init.d is working or not, reboot your phone and navigate to /data...you should find a Test.log in there...If it is present, congrats, you have init.d support!
Download:
If you have already read all the instructions and understand them, then click here to download:
term-init.sh
Feel free to posts questions below...I will try my best to help...
Hit the thanks button if you liked my work...it gives me a boost!
Please don't mirror / modify my work, ask for permissions first...​
Click to expand...
Click to collapse
its not working
ranjitkhera said:
its not working
Click to expand...
Click to collapse
Well, are the all the files present? Did you follow all the steps? I suggest you to reinstall busybox by using the link I gave...then attempt this again...
This mod work on MIUI UK official for desire s
Tested with v6 supercharger by zep
Thanks a lot
Sent from my HTC Desire S using xda app-developers app
Hi ,
I use an Motoluxe xt615 , i Fllow your guide step by step . But nothing.
The Phone Restarts an in /data is no Test.log
Busybox install Terminal install . Terminal say all is ok but the test.log fails. After Reboot i cant find it.
Sorry for my bad Englisch
hexer7568 said:
Hi ,
I use an Motoluxe xt615 , i Fllow your guide step by step . But nothing.
The Phone Restarts an in /data is no Test.log
Busybox install Terminal install . Terminal say all is ok but the test.log fails. After Reboot i cant find it.
Sorry for my bad Englisch
Click to expand...
Click to collapse
Ok...let me interpret...you installed busybox by using the link I gave, then you ran this in terminal emulator right? Can you please give me a screenshot of your terminal emulator running this script? Thanks...
Ryuinferno said:
Ok...let me interpret...you installed busybox by using the link I gave, then you ran this in terminal emulator right? Can you please give me a screenshot of your terminal emulator running this script? Thanks...
Click to expand...
Click to collapse
how can i make this???
ah ok
http://s1.directupload.net/file/d/3042/ofxoh9z3_png.htm
Err...run the script in terminal emulator, when it finished running, take a screenshot...
Ryuinferno said:
Err...run the script in terminal emulator, when it finished running, take a screenshot...
Click to expand...
Click to collapse
http://s1.directupload.net/file/d/3042/ofxoh9z3_png.htm
hexer7568 said:
how can i make this???
ah ok
http://s1.directupload.net/file/d/3042/ofxoh9z3_png.htm
Click to expand...
Click to collapse
Ok...by looking at your first few lines...I saw that su permissions for terminal emulator are not granted properly...and my script seems to be only running in the surface (only shows the text)...did you reboot after installing busybox? And by the way, please check your /system/etc...is there a init.d folder and a file named "install-recovery.sh"? And what andriod version are you using?
P.s. A working example should be like my screenshot on the first page...the first few lines in your screenshot should not appear...
Ok...I will include a flashable zip soon...cause terminal emulator does not seem to work with some...
Ryuinferno said:
Ok...by looking at your first few lines...I saw that su permissions for terminal emulator are not granted properly...and my script seems to be only running in the surface (only shows the text)...did you reboot after installing busybox? And by the way, please check your /system/etc...is there a init.d folder and a file named "install-recovery.sh"? And what andriod version are you using?
P.s. A working example should be like my screenshot on the first page...the first few lines in your screenshot should not appear...
Click to expand...
Click to collapse
1 Reboot after busybox install no
2, no
3. no
That's why...the script did not have the correct permissions to run...did you grant terminal emulator su access when you type "su"? Try installing busybox again, reboot, run the script and reboot again...
Ryuinferno said:
That's why...the script did not have the correct permissions to run...did you grant terminal emulator su access when you type "su"? Try installing busybox again, reboot, run the script and reboot again...
Click to expand...
Click to collapse
When i type su , the first massage is "log_write: cannot open Device" , then after this massage i have su
When you type "su" for the first time after installing terminal emulator, a pop up will appear, asking you to grant or deny superuser access...did that happen?
Ryuinferno said:
When you type "su" for the first time after installing terminal emulator, a pop up will appear, asking you to grant or deny superuser access...did that happen?
Click to expand...
Click to collapse
i install emulator new, and i lock that
Ok..seems that the su access in your terminal emulator is not working well, so I will upload a cwm zip soon...wait for that...

BootBuddy - Run Boot Scripts from SDcard (a safe alternative to init.d)

INTRODUCTION:
Boot Buddy will allow you to run Linux shell scripts when your Android device is booting up. It will run your scripts early in the boot process, before the home screen appears.
The intended audience is generally intermediate to advanced users, and those who want to play with shell scripting on their device.
FEATURES:
BootBuddy is similar to init.d scripts, but with a core difference that it stores boot scripts on your SDcard instead of the internal system. This allows for several interesting enhancements. Feature listing-
Much more Safe than init.d. If you have a script that is malfunctioning, just boot with the sdcard out, and put the sdcard back in after your device reaches home screen. Your device is Saved, No Problem!
Boot Buddy is designed from the start to run scripts right from your SDcard. Just download any scripts to your boot_buddy_scripts directory and they're ready to run. (No more screwing around with permissions and files in your /system/etc/init.d/*)
SDcard storage allows you to copy a script to another device, or multiple devices easily.
Boot Buddy's author has several years of scripting and programming experience. It is streamlined, fast, and doesn't perform worthless functions like repeatedly logging the authors name and time (*hint to a t-init author*).
Clear goals of making operation simple, intuitive, and clean.
If you're currently using an "init.d" solution, BootBuddy can integrate seamlessly with it.
If you try BootBuddy and you don't like it, the installer also works as an uninstaller for easy clean removal.
BootBuddy is Open Source GNU GPL. Open for anyone to modify and improve upon.
As a developer, I make software to operate the way I would want if I were an end user, because I actually do use it, and I am an end user like you.
REQUIREMENTS:
Android 4.0 and up
Rooted device
An sdcard
Script Manager Free (or any other app that can run scripts as root)
Boot Buddy Installer bb_install.sh
INSTALL:
Start Script Manager, and allow/grant root access.
Navigate to the bb_install.sh file.
Tap on the file to show the menu options.
At the top, highlight the "Su" icon.
On the top-left, tap "Run".
The script will run quickly. It will automatically detect your sdcard location and create a folder on your sdcard named "boot_buddy_scripts". In that folder, you put the scripts you want to run at system boot. A log file will be kept at /data/boot_buddy.log
If you need your scripts to run in order, they are ordered by filename using the busybox "sort" program. They will run in alphabetical order using this format 0-9A-Za-z.
YOUR FIRST SCRIPTS: (OPTIONAL)
Here are a couple example scripts you may use.
The Android /system is normally mounted with read-only permissions by default. We will change that with the first script listed below. It will cause /system to be remounted to read-write permissions during boot.
The second script will create a file at every boot named /mnt/sdcard/sys_mount_info.txt. That txt file will give us information about how /system is currently mounted.
Download the file 00rw_system.sh into your boot_buddy_scripts folder.
Download the file 99sys_mount_info.sh into your boot_buddy_scripts folder.
Reboot your phone.
That's it, you just installed 2 new scripts and had them run at boot. It's Really just that simple to add startup scripts to your system.
To verify they are running, use any text viewer to open the file /mnt/sdcard/sys_mount_info.txt. It may show more than one line of text. There should be a line similar to this:
/dev/block/(device specific text) /system (fstype) rw,(more text)
The rw means that /system was successfully remounted as read-write during boot.
At any time you can delete either script if you choose. Easy!
UNINSTALL:
If for any reason you find you don't want or don't like Boot Buddy, you can cleanly uninstall it using the installer bb_install.sh. These instructions are almost identical to installing. (All match the installation steps, except step 4)
Start Script Manager, and allow/grant root access.
Navigate to the bb_install.sh file.
Tap on the file to show the menu options.
Type --uninstall in the text area labeled Arguments.
At the top, highlight the "Su" icon.
On the top-left, tap "Run".
Boot Buddy will be uninstalled. It will not remove the contents of your boot_buddy_scripts folder. If you have an "init.d" system installed, it will cleanly remove only Boot Buddy parts and leave the rest.
MUST READ
ADVANCED NOTES:
Boot Buddy will Not cause harm to your system, but it may not work on custom roms. Also, it may fail to detect the real location of your SDcard. It requires that /system/etc/install-recovery.sh is run during the boot process, and that file will be created if it does not exist. Also the file /data/boot_buddy.sh will be created. The script /system/etc/install-recovery.sh will run /data/boot_buddy.sh. The script /data/boot_buddy.sh will run the scripts on your sdcard. The file /data/boot_buddy.log will log any script output.
For Windows and Mac users- If you download the installer to your pc first, do not edit the installer with a text editor. Your computer will add hidden markers at the ends of each line that will prevent the installer from running. If you want to edit it, you should do so on a Linux pc or directly on your Android device.
Tell us about your results!!!
BootBuddy source code: http://github.com/Sepero/bootbuddy
NOTE : I AM NOT A DEVELOPER I AM ONLY SHARING THIS. So Try On Your Own Risk. I Can't Help Anything.
Credits :
[email protected]
Script mgr says I'm not root, despite me in a root terminal elsewhere. wtf ?? ...
I'm not root in script mgr., even though I'm showing up as root in terminal.
I've installed Super user (chains sd ), just in case the App doesn't support my other Supersu App or similar.
I've utilised the su icon and run.
I did tick run as executable.
No reboot tried.
What am I missing ??
Please advise.
I give you 5 stars to the thread
Almost first!!! haha.... this is awesome dude this could be HUGE.
Steve Eligoyo said:
I'm not root in script mgr., even though I'm showing up as root in terminal.
I've installed Super user (chains sd ), just in case the App doesn't support my other Supersu App or similar.
I've utilised the su icon and run.
I did tick run as executable.
No reboot tried.
What am I missing ??
Please advise.
Click to expand...
Click to collapse
You must to select root when start on script mgr, you have skull head with crossed bones
Steps to complete failure: Page 96 ?? ...
Here are the steps I've taken to get kicked in the teeth:
Boot phone > menu > script mgr. > start > scroll to file (in this case bb _install.sh ) > open file > tick su ( tried boot and bgr several times, nada amigo ) as instructions state > run > unexpected oper error: your not root > rinse and repeat sixty times > open terminal > su > Works just fine > Post my question on xda in the WTF Thread
Update:
After creating the directories and files needed to make this train wreck into a working setup, (obviously a few are missing here, working on it), I reopened script mgr and browsed the file system, which shows bb _install.sh file (and the other two in this
Thread as well) with the green su skull and crossbones with the boot dot next to those skulls, yet the apps shell /console says oper error - Your not root.
Again, I open terminal, su > enter > Viola!, I'm root.
I've installed the sdcard v. of script mgr as well and I get a message stating /data/system/xbin does not exist.
I'll likely need to tweak the script mgr settings to /sdcard 0/externalsd /directory bind /system /xbin/bb _install.sh - something like that.
Still doesn't explain why the app is putting the brakes on root terminal in the nag screen.
Any ideas ??
MAN THANK YOU !!!! as a noob i couldn´t get init.d to work right. so i tried your script on the xperia z3c with stock 4.4.4
to make it compatible with z3c you need to edit the file /data/boot-buddy.sh after the installation
and replace both
/boot_buddy_scripts/
with
/storage/emulated/legacy/boot_buddy_scripts/
or
/storage/sdcard1/boot_buddy_scripts/
or another prefered location
then make a new folder boot_buddy_scripts in the location.
really it executes the scripts way before the apps are starting , this is so nice and will be on my phones from now on !
edit: i also now changed the log file creation to the sd card for quick access (most filebrowsers open there by default)..
the logfile is major awesome btw if something didn´t go right , its easy to debug , thanx alot again
Won't install says I don't have busybox. I have it but it has to go in system bin instead of xbin. Amy way to get this working?

[How To][Linux] Optware + ssh + samba + transmission + flexget

Yep, you read that correctly. I have optware, ssh, samba, transmission, and flexget working on my Minix X5 Mini. This should work for any rooted device which has an adb connection enabled. This will work on the original ROM. In fact, I use the stock ROM. For those not using a Minix device this should work on any ARM device. Sorry but all the binaries are built on ARM.
JUST AS EVERY OTHER DEVELOPER: I AM NOT RESPONSIBLE IF YOU BRICK YOUR DEVICE! MAKE A BACKUP!
Requirements:
Linux box with adb (don't ask me about windows, I don't support bad habits)
clockworkmod (for a backup)
root
internet connection
Process:
Make a backup of your ROM!
Download files (gitHub)
You have two options here:
Download the zip via https://github.com/erichlf/AndroidSeedBox/archive/master.zip and unzip it.
Clone the repo using git via 'git clone [email protected]:erichlf/AndroidSeedBox.git'
Make script executable
chmod +x optware-etc.sh
Obtain adb connection to device (covered in another thread)
Gain root access on local machine (adb seemed to require this for things to work)
sudo su
Run script and follow directions
./optware-etc.sh
Use SManager to run /opt/home/root/sysinit at every restart.
Notes:
The script can be modified to change the various programs that I install. You could exchange transmission for deluge for example.
Transmission can be accessed from the minix through localhost:9091 or from some other machine using your ip-address and the port 9091. If that doesn't work you should edit the config file located at /opt/home/root/.config/transmission-daemon/settings.json
username: root
password: you provided this in the install script
Without SManager nothing will start automatically. However, if you have a ROM which has init.d support you can move the scripts in /opt/etc/init.d to /etc/init.d I would suggest maybe linking the two instead of just moving the scripts or possibly adding a script to /etc/init.d which runs the items in /opt/etc/init.d The reason is because when installing things using ipkg the startup scripts will be placed in /opt/etc/init.d and not /etc/init.d However, it is extremely important that optware is started, and this is partly what sysinit accomplishes.
To list available packages
ipkg list
To install a new package use the command
ipkg install <new package>
To remove a package use the command
ipkg remove <package to remove>
cron is weird and I couldn't get it to work like it should, but I got it to work
While on the Android device (ssh or terminal emulator)
Create a .crond file in the home directory of your device (/opt/home/root/) with some schedule in it. Remember to leave a blank line at the end of the file.
Tell cron about the .crond file
crontab -u root /opt/home/root/.crond
Make sure cron sees the cron file
crontab -l
If you want to edit your cronfile use a text editor and edit the file directly and then tell cron about the file again.
Many things are installed in what seem like strange places, so use
which <binary you are looking for>
Feel free to help develop the code. I think what would be best is an update.zip or a CWM flashable zip. Right now I don't know how to do this, but once I get more time I will look into it. So, any help on this front is welcomed.
Enjoy!
I really wish you would have kept the repo up. It seems kind of pointless to go through all that trouble just to delete the repo and leave people wondering what you did.
I have been busy and didn't update this particular post, since there had been no activity on it.
git clone [email protected]:erichlf/androidseedbox.git
https://bitbucket.org/erichlf/androidseedbox/get/master.zip
Sorry, I didn't need to be rude. I was just excited to find this and then sad when it was gone. Thanks for pointing me in the right direction!

[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 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

Categories

Resources