Database Info

Android/Linux question for rooted Galaxy Tab

Hi there
My knowledge of Android is very limited, I know a little about Linux from Ubuntu at command promt level, but not enough to fix this issue I'm having. Any help would be much appreciated.
I wish to modify a file which Android is telling me is locked. It's \system\etc\bluetooth\audio.config
I have found a modification to this file which may help me in connecting the Tab to a bluetooth peripheral I have.
I have rooted the Tab
I have installed a root file manager
I have installed a terminal app
I have tried to chmod this file when logged in as su, but this refused so still I cannot edit the file.
I read somewhere about mounting the system folder as rw, but this is a bit beyond my knowledge. So if this is necessary I need walking through this step-by-step.
Could someone please help me by posting some instructions to get me to the point where I can edit the file audio.config?
Many thanks
Gary

su
mount -o remount,rw /dev/mtdblock3 /system
You may still not be able to modify a file so copy it to /mnt/sdcard/file and edit it there and rename the source file when ready to mv it back in.
mount -o remount,ro /dev/mtdblock3 /system
when done.
This worked for me on my new Galaxy Tab Wifi after using A4 to root it.

[Q] Need adb code help to resolve small issues

Hello everyone,
Well I am finally cooking with gas lol and making progress! I'm just about done getting a clean root and the small adjustments I want to my device. Could anyone help me with adb code solutions to the following...
I have root access! BUT:
1) Is -I / system/bin/su: does not exist...should I rename it or delete it and how would I do that?
2) Is -I / system/xbin/su: is rooted correctly but I need to know how to execute the file on adb
3) Is -I /sbin/su: how do I grant permissions to this file?
4) Is -I /system/xbin/sudo: does not exist...should I rename it or delete?
Both root user and group I'd's are good
System Environment PATH: /sbin/vendor/bin /system/sbin / system/bin /system/xbin
adb shell setting for standard access, stored in default.prop, is configured as: shell (non root) user - r.secure=1 no idea how to fix
Hopefully I have laid this out nice and neat so the code can be placed under each line idem so my novice self can succeed and whatever kind soul takes the time to help won't be waiting there efforts...
Thanks so much on advance...
ThisguyTO - Garrett

What are you trying to do?
Sent from my Nexus 5 using Tapatalk

just flash supersu in your custom recover(assuming you flashed a custom recovery). adb isnt need to gain root. latest supersu http://download.chainfire.eu/supersu

Deleting file after system start not working with tasker.

Hi all,
because there is actually no persistend root on the Huawei Mate 9 (system modifivations are discarded after reboot) i would like to run system modifications directly after booting the device.
To do that i am going to use tasker.
For example i want to delete the "camera_click.ogg" file to avoid sounds when making photos with WhatsApp.
Using root explorer i only have to tap on mount system r/w and delete the file.
So i tried the following code in the android shell (which can be run within tasker):
Code:
su
mount -o rw,remount /system
rm -f /system/media/audio/ui/camera_click.ogg
But the system is still not writeable! And mountimg via root explorer only works again after a reboot...
Once with a similar code i got an error message like "resource busy".
What can cause this Problem and how can i delete this system file?
(note: i am not so familiar with Linux, only Raspberry Pi knowledge )
Thank you for helping in advance!

It is same dm-verity problem.
You have to modify boot to turn dm-verity off.

5[Strogino] said:
It is same dm-verity problem.
You have to modify boot to turn dm-verity off.
Click to expand...
Click to collapse
Thank you for your answer!
I will try this tutorial:
https://forum.xda-developers.com/mate-9/development/root-root-mate-9-t3556590
Hope it works...

[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

userdebug / eng build needed

Hi folks,
I have seen some great quality ROMs here, big thanks for your work/support for those.
For a project, I need to alter the config settings of the wifi baseband in my Moto G pro, which I can access at /vendor/etc/wifi/WCNSS...ini.
My problem is that even with a rooted phone (su on adb shell working fine) and custom ROMs, the /vendor partition is remaining Read-Only and I cannot change this config file. I have had access to debug builds before that have allowed me to change this file by pushing/pulling using adb, but with rooted stock or rooted custom ROMs I am not able to use adb root (Production Build) or adb push (read-only file system) or adb disable-verity (User build).
Trying to use shell to remount as r/w:
# mount -o rw,remount /vendor
'/dev/block/dm-4' is read-only
I think my solution here is to try running a custom ROM that is built as 'userdebug' or 'eng'. Could you point me to any ROMs available that run in these modes? or is anyone in a position to build these quickly?
Thanks in advance for your pointers
Liam
Moto G Pro XT2043-7

liam_L said:
Hi folks,
I have seen some great quality ROMs here, big thanks for your work/support for those.
For a project, I need to alter the config settings of the wifi baseband in my Moto G pro, which I can access at /vendor/etc/wifi/WCNSS...ini.
My problem is that even with a rooted phone (su on adb shell working fine) and custom ROMs, the /vendor partition is remaining Read-Only and I cannot change this config file. I have had access to debug builds before that have allowed me to change this file by pushing/pulling using adb, but with rooted stock or rooted custom ROMs I am not able to use adb root (Production Build) or adb push (read-only file system) or adb disable-verity (User build).
Trying to use shell to remount as r/w:
# mount -o rw,remount /vendor
'/dev/block/dm-4' is read-only
I think my solution here is to try running a custom ROM that is built as 'userdebug' or 'eng'. Could you point me to any ROMs available that run in these modes? or is anyone in a position to build these quickly?
Thanks in advance for your pointers
Liam
Moto G Pro XT2043-7
Click to expand...
Click to collapse
This may help
[Closed] Universal SystemRW / SuperRW feat. MakeRW / ro2rw (read-only-2-read/write super partition converter)
Welcome to the one and only, the original, universal, System-RW / Super-RW feat. Make-RW / ro2rw (read-only-2-read/write super partition converter) by lebigmac Also known as: THE-REAL-RW, FULL-RW, EXT4-RW, EROFS-RW, EROFS-2-RW, F2FS-RW...
forum.xda-developers.com

Thank you @sd_shadow for your helpful response.
I have spent some time playing around with various options (and some time pretending my problem doesn't exist ).
Both the SystemRW script, and the superrepack tool linked in thatpost were unsuccessful for the Moto G Pro.
SystemRW script:
- v1.31 was kind of promising - While running the script, it printed that /vendor was "already R/W". After running, sure enough the partition kind of thought it was R/W, but was throwing other errors that showed it clearly actually wasn't. In the end the script threw error 73 and failed to create super_fixed.img file.
- v1.32 at least knew that /vendor was RO, but also failed to create super_fixed.img file (73).
I have log files handy if @lebigmac is interested.
- The v1.32 repair tool was useful in extracting information, and it managed to find a super_fixed.img file. So I tried to flash manually, but the phone was stuck during boot, so I'm guessing it wasn't created properly.
MY SOLUTION:
In the end, what solved my issue was to create a new Magisk module that would replace the config file I needed on every boot- seeing as I was using Magisk to get the root access anyway, this will be a good solution for my case.
For anyone interested, go and have a look at Magisk documentation:
Magisk Github Dev Guides
To simplify: you place the module files in /data/adb/modules/Your_Module,
and anything inside Your_Module/system/... will replace that in various partitions. So for my case I wanted to replace /vendor/etc/wifi/... , I created My_Module/system/vendor/etc/wifi/config_file_name.ini

sd_shadow said:
This may help
https://forum.xda-developers.com/t/script-android-10-universal-mount-system-read-write-r-w.4247311/
Click to expand...
Click to collapse
Hi @sd_shadow thanks for your helpful response.
Have you tried my script on your device yet and did it work? Is it a Xiaomi device?
liam_L said:
Thank you @sd_shadow for your helpful response.
I have spent some time playing around with various options (and some time pretending my problem doesn't exist ).
Both the SystemRW script, and the superrepack tool linked in thatpost were unsuccessful for the Moto G Pro.
SystemRW script:
- v1.31 was kind of promising - While running the script, it printed that /vendor was "already R/W". After running, sure enough the partition kind of thought it was R/W, but was throwing other errors that showed it clearly actually wasn't. In the end the script threw error 73 and failed to create super_fixed.img file.
- v1.32 at least knew that /vendor was RO, but also failed to create super_fixed.img file (73).
I have log files handy if @lebigmac is interested.
- The v1.32 repair tool was useful in extracting information, and it managed to find a super_fixed.img file. So I tried to flash manually, but the phone was stuck during boot, so I'm guessing it wasn't created properly.
MY SOLUTION:
In the end, what solved my issue was to create a new Magisk module that would replace the config file I needed on every boot- seeing as I was using Magisk to get the root access anyway, this will be a good solution for my case.
For anyone interested, go and have a look at Magisk documentation:
Magisk Github Dev Guides
To simplify: you place the module files in /data/adb/modules/Your_Module,
and anything inside Your_Module/system/... will replace that in various partitions. So for my case I wanted to replace /vendor/etc/wifi/... , I created My_Module/system/vendor/etc/wifi/config_file_name.ini
Click to expand...
Click to collapse
Hi @liam_L
Please feel free to PM me your log files from this folder on your phone and I will look into your issue with my script
/data/local/tmp/systemrw_1.32/log/
Error 73 is probably some kind of selinux kernel panic mode that is triggered if too many I/O operations happen in a short time period. The included sysrw_repair script (Linux only) should be able to fix that.
If you want to do adb root you need to patch your adbd daemon to run as root user. More info here