Database Info

[GUIDE][SCRIPT] How to root Android x86 4.3

As we all know, Android 4.3 brought with it some extra security features which caused some small issues with root. These have been solved by the likes of Chainfire and other developers, meaning we have root once more. This is their work, I've just botched it together to work on the Android x86 4.3 system, which works slightly differently
You will need:
A device with Android x86 4.3 on it
Optionals:
Another Linux based OS - this can be an OS on another partition on the device or a live disk/USB
Root permissions in that second OS and access to the terminal
Knowledge of which partition Android x86 is installed onto and which is its root folder (if you didn't mess with that, it tells you in the script)
Instructions:
On Android x86:
Download the attached zip and extract it using a file manager
Press Alt+F1 and use "cd" to change directory to where you extracted the zip
You should go as far in as the "README" and "install.sh" files
Run:
Code:
sh install.sh
Follow the instructions on-screen. It tells you the rest.
On a linux boot:
Download the attached zip and extract it to somewhere memorable
Open your terminal and use "cd" to change directory to where you extracted the zip. You should go as far in as the "README" and "install.sh" files
Run:
Code:
sh install.sh
Follow the instructions on-screen. It tells you the rest.
Reboot back into Android x86, it should have root now
Changelog:
v2:
Included version for Android x86 boot, through the Alt+F1 terminal
Made it a bit simpler
Screenshots
{
"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"
}
Credits
@Chainfire for SuperSU and all the files included that the script installs
The SuperSU thread, don't forget to thank on there
The Android x86 project for the OS itself and the init.sh file, which is patched as the install-recovery file is

Hello..
I try to run the install.sh but it said
"This script needs root. Enter your password to continue:
sh: 0: Can't open .install.sh"
I ran it with sudo permission. My Ubuntu is on sdb6 and and android is on sdb7.
Please assist.
Just wondering? Can I just copy the the system folder and let it overwrite (merge) the system folder in the android partition. Also what permission do I need to change for what folder if I were to do this manually.
Thanks minhgi

It hasn't extracted properly, the .install.sh file is in the zip with the install.sh
Just in case, for the next release (in testing now, can be run from the Android x86 boot itself), I made it ./.install.sh, which should work

Here comes version 2:
Changelog:
Included version for Android x86 boot, through the Alt+F1 terminal
Made it a bit simpler

Thanks Quinny,
It is working. Somehow when I downloaded the attachment the first time, the script folder was not there. So there was not script to run. Anyway, I did it through the Ubuntu terminal it is working for me.
---------- Post added at 02:49 PM ---------- Previous post was at 02:29 PM ----------
Opps..I said it to soo. I using an android build 4.3 from www.tabletx86.org and it use chainfire SU. It also seem like your rooting method use chainfire su. When I try to use root explorer to enable r/w permission, the app just force close. Also I try to launch chain su, it also force close. I am not sure if there is an incompatibiltiy issue there. I use the rom build from tabletx86 b/c it have broadcom wifi working for my laptop.
The android 4.3 from android-x86.org does not. Can you test the build from www.tabletx86.org? it was compile on 08-02-2013.
Thanks again.

minhgi said:
Thanks Quinny,
It is working. Somehow when I downloaded the attachment the first time, the script folder was not there. So there was not script to run. Anyway, I did it through the Ubuntu terminal it is working for me.
---------- Post added at 02:49 PM ---------- Previous post was at 02:29 PM ----------
Opps..I said it to soo. I using an android build 4.3 from www.tabletx86.org and it use chainfire SU. It also seem like your rooting method use chainfire su. When I try to use root explorer to enable r/w permission, the app just force close. Also I try to launch chain su, it also force close. I am not sure if there is an incompatibiltiy issue there. I use the rom build from tabletx86 b/c it have broadcom wifi working for my laptop.
The android 4.3 from android-x86.org does not. Can you test the build from www.tabletx86.org? it was compile on 08-02-2013.
Thanks again.
Click to expand...
Click to collapse
I'll have a go at some point, I'm on a slow connection currently so it might be a while

Quinny899 said:
I'll have a go at some point, I'm on a slow connection currently so it might be a while
Click to expand...
Click to collapse
not a problem. Please take you time. these builts are are preview version anyway.

minhgi said:
not a problem. Please take you time. these builts are are preview version anyway.
Click to expand...
Click to collapse
I looked this morning and it can't be run from the boot as it's got a broken superuser installed which means I can't mount the system. Don't see why it would force close though

So I tried doing the script via alt+f1 and it says its in root, then when the script runs it shows that it cant mount permission denied and it fails to remove old files and fails to chmod also. Any help would be appreciated. Thanks

wolfballz said:
So I tried doing the script via alt+f1 and it says its in root, then when the script runs it shows that it cant mount permission denied and it fails to remove old files and fails to chmod also. Any help would be appreciated. Thanks
Click to expand...
Click to collapse
If you're using TabletsX86's build, that's why, also, if you didn't allow /system to be mounted during install, then you're out of luck

Quinny899 said:
If you're using TabletsX86's build, that's why, also, if you didn't allow /system to be mounted during install, then you're out of luck
Click to expand...
Click to collapse
using latest build from android-x86.org and I didn't recall seeing anything about being able to mount /system during install.

wolfballz said:
using latest build from android-x86.org and I didn't recall seeing anything about being able to mount /system during install.
Click to expand...
Click to collapse
There is, right before you install.
Like so:
(Not my image)

Must have breezed right by it. Since i have it with windows how can i remove my current android install and start over? I ran the install again and i dont get that /system question at all.
So i tried installing on a virtual machine and i get the /system option now. Thanks for the help
Sent from my SCH-I535 using Xparent Blue Tapatalk 2

After installing on a virtual machine and mounting /system thw script ran without error. Rebooted but didnt see a superuser app so i installed supersu. Installed and opened root explorer and when trying to mount anything RW it hangs and then root explorer says not responding. Anything else i can try?
Sent from my SCH-I535 using Xparent Blue Tapatalk 2

Hello! I installed this, then a custom font. When I rebooted, I get stuck in a terminal. Any help?

Yoyodude1124 said:
Hello! I installed this, then a custom font. When I rebooted, I get stuck in a terminal. Any help?
Click to expand...
Click to collapse
Most likely the font. Did you set its permissions correctly?
Sent from my Galaxy Nexus using Tapatalk 4

Works perfect. I've used it twice now. Thanks.
If you get stuck in terminal you can type "start" to boot android.
Sent from my Lenovo Thinkpad Edge using Tapatalk 4

Unlockable bootloader/custom roms?
Is there any way to get custom recoveries on this, so we could install custom ROMs?

Yoyodude1124 said:
Is there any way to get custom recoveries on this, so we could install custom ROMs?
Click to expand...
Click to collapse
Nope. And there won't be ROMs like CM or the like, x86 is completely different to ARM and they're highly unlikely to make it compatible

I also only get the question whether to install /system as r/w with builds before 4.3. Using the boot image of 4.2 of course results in a mess but it takes me to the screen where I can choose to use system as r/w or read only.
Tried with a freshly fixed mbr and clean install.

Root tool DirtyCow Apk && adb

Hi,
I have developed a tool to exploit the dirtycow vulnerability and get TEMPORAL ROOT
It bypass the selinux in lollipop 32bits system only, we are working now in a 64bits and Marshmallow version and will be soon, have a lot of work to do it universal.
Im bringing 2 tools, one apk (no computer required) and one rar for adb and linux.
With this tool we will access to those partitions and start the attack there, but in the actual state if you have locked your bootloader a good choice is to have root even temporal one.
·APK
Required: SDCARD
The apk exploits this vuln in the vold context so, is necessary to have a sdcard and mount or extract it, when the app requires, one time per session.
This tool has some utilities for flash boot and system partition, also for backup and 2 methods of root:
·Attack init process (lollipop 32 bits only)
·Attack app_process.(all devices, not really good)
·Get root
Uninstall any supersu manager before root.
The way to use this app is first click in check perms(optional) and you will see if you have permissions to /init file.
If you have permisisons and lollipop 32 you can use the first method to get root.
Also in check permissions you will see if you have rights to backup/flash boot and system partition.
The process takes until 2 minutes to finish so wait please and watch the log window.
# ISSUES #
If you get reboot after get root you can:
-Clean init (restore init process sometimes crash the device, but is safe)
-Install selinux permissive (Set permanent the new selinux policy, not tested)
The first option is safe you just can get a reboot.
The second option is just tested in 3 devices(oppo,xperia,Moto E), so test it with a recovery system working, can break some selinux rule..
·ADB
The adb rar contains some utilities to get root via run-as and init and is only working in Lollipop 32bits.
To execute it:
-Pass rar:"nox"
-Extract the rar in /data/local/tmp/
Code:
chmod 755 /data/local/tmp/exploit.sh
cd /data/local/tmp/
./exploit.sh
This process take some time 1-2 minutes but you will see the progress in the console, please wait,
After will ask to turn off bluetooth do even sometimes is not required, it can accelerate the process.
It will ask to install selinux permissive, if you don't have reboot problems, don't install it, otherwise be sure you have a recovery system working and a stock rom ready to flash, this feature is stable but need more testing.
if all is ok you will see this:
Code:
#Type run-as -s1 to get a shell"
#Type run-as -s2 to execute su daemon"
The run-as -s1 give you a shell with init context but some restrictions because selinux autotransfer domain to run-as
The run-as -s2 will execute su dameon and a su init context with no restrictions.
# ISSUES #
If you get reboot after get root you can:
·mount system partition with flag abort:
Code:
mount -o remount,abort /system
You won't able to mount system in write mode.
This app is in BETA BETA state for now, just 7/9 devices passed not bad at all
I'll add more devices in the list soon
List of rooted devices:
Moto G 5.1 lollipop
Xperia 5.1 lollipop
Oppo 5.1 lollipop
Emulator 5.1 lollipop
XT1528 (MOTO E Verizon prepaid) 5.0.2 lollipop(reboot issues)
Asus Zenfone Go ZB452KG Lollipop(5.1.1)
Smartfren Andromax A / Haier a16c3h (Lollipop 5.1 Firmware 12.2)
Version:0.4
Adb:http://www.mediafire.com/file/r3i900n7jb2zfoo/EXPLOIT_ADB.rar
Apk:http://www.mediafire.com/file/38tyscsaxms00sa/croowt%282%29.apk
Implemented selinux pemissive after reboot.(adb,apk)
Enforce mode working.(adb,apk)
Version: 0.3
Fixed bug creating bl instruction.
Version: 0.2
-Fix bug in apk for some devices
Version: 0.1
-More compatible adb with lollipop 32 bits
-Fixed bug in the shellcode.
-64 bits version of run-as-dirtycow.
Todo:
-Working in Marshmallow 32 bits.
-Apk some fix.
Thanks to n0x for his great help debugging the shellcode issue in Moto G

Great work!
Waiting for 64 bit

I will gladly test with my v10 I've been able to get a temp root shell with dcow. Happy holidays!

Sweet ! Has anyone tested on Note 4? N910A on 5.1.1
I'm currently on 6.0.1 MM so I'm waiting for that release.
Anyone know if this will work with the November Security patch of 2016?
Sent from my SAMSUNG-SM-N910A using Tapatalk

Really cool. I am having a problem trying to connect my device over adb wifi and now this!!! I have a locked head unit and i can't install any apps (all installations blocked and developer mode, usb debug all hidden. ) any way for me to install this onto my phone and attack my device via bluetooth or something? Or autorun once connected to usb? It's a long shot but hey its Christmas!!
Merry Christmas by the way

Can we have access to the run-as-dirtycow source code?
Thanks.

Exploit process
For the developers that are testing this exploit or want to know how it works deeply:
First we dirtycow some privileged process, for example run-as has suid 0 given by selinux capabilities not by the bit setuid.
When we have overwritten run-as, this binary can read /init path, so we copy to other place with our run-as "trojan".
In our run-as we need to put some code to read files, my run-as-dirtycow does:
run-as /init
Will print this file to the stdout(console), if we redirect this output to a file:
run-as /init > /data/local/tmp/init.dmp
We copy /init file through our dirtycowed run-as that has root privileges, and is permitted by Selinux.
We patch init.dmp to create our init.patch with a shellcode to load new policy.
We will use run-as to dirtycow again our init.dmp but patched with a shellcode.
So our run-as trojan also will have the dirtycow exploit and when we exec this binary with the right arguments also will dirtycow any file with read permissions to root.
run-as /init /data/local/tmp/init.patch
Once finish and when the new policy is loaded exec run-as trojan wiht the special parameter -s1 or -s2 give to you a shell root or install su in the device TEMPORAL, no modifies any partition but mount a ext4 partition in /system/xbin with the su binary.
Well this is the process to do it in adb shell, in the apk i am using fsck_msdos to do all this chain of steps.
I like to get some different init from lollipop 32 bits and Marshmallow 32bits to adjust the patcher to Marshmallow.

jucaroba said:
Can we have access to the run-as-dirtycow source code?
Thanks.
Click to expand...
Click to collapse
Is very simple just have the dirtycow exploit original and some code to copy files read and puts.
Anyways soon ill post here, has no many secrets lol, just copy file or execute sh, the main problem now is the patcher, to make it working in Marshamallow and 64bits, i don't have any device with 64bits, yes one xperiaZ that i can install a custom rom with Marshmallow.
But i think the first is to check if the patcher is working in lollipop32 bits well, even ive tested 2 devices and reversed some other inits is not enough to be completely sure that all is ok.

kryz said:
Is very simple just have the dirtycow exploit original and some code to copy files read and puts.
Anyways soon ill post here, has no many secrets lol, just copy file or execute sh, the main problem now is the patcher, to make it working in Marshamallow and 64bits, i don't have any device with 64bits, yes one xperiaZ that i can install a custom rom with Marshmallow.
But i think the first is to check if the patcher is working in lollipop32 bits well, even ive tested 2 devices and reversed some other inits is not enough to be completely sure that all is ok.
Click to expand...
Click to collapse
Thanks for your answer.
I'm trying to use your exploit to be able to read my /data/misc/vold/expand_*.key file. My wife has a Moto G 2014 mobile with official (non rooted) Android 6 Marshmallow. The bootloader is locked. She has deleted accidentally all the pictures in her SD card, that is configured as adopted card (not portable). I have made a cloned copy of the SD in my linux laptop with dd command, but I can not mount the partitions in the SD because I have to know the encryption key.
I can not unlock the bootloader, because the phone will be reseted to factory and the encryption key will be deleted. And I can not read the key file without being root, because of the permissions of the file. I have tried your run-as-dirtycow trojan in the phone, and I can read files I have no permissions for, such as /init.rc. The only missing piece now is that I don't know the exact name of the key file. I only know that it is of the form "expand_*.key". Can your trojan run-as-dirtycow be modified to be able to read the files with this pattern name in a given directory?
Thanks in advance.

kryz said:
Is very simple just have the dirtycow exploit original and some code to copy files read and puts.
Anyways soon ill post here, has no many secrets lol, just copy file or execute sh, the main problem now is the patcher, to make it working in Marshamallow and 64bits, i don't have any device with 64bits, yes one xperiaZ that i can install a custom rom with Marshmallow.
But i think the first is to check if the patcher is working in lollipop32 bits well, even ive tested 2 devices and reversed some other inits is not enough to be completely sure that all is ok.
Click to expand...
Click to collapse
I'm trying to root my boost max+ running 5.1.I tried the check perm option but couldn't remount sdcard,it just froze.Upon reboot it hang at starting apps.Had to remove sdcard to get phone to boot properly.
Sent from my N9521 using Tapatalk

tnomtlaw said:
I'm trying to root my boost max+ running 5.1.I tried the check perm option but couldn't remount sdcard,it just froze.Upon reboot it hang at starting apps.Had to remove sdcard to get phone to boot properly.
Sent from my N9521 using Tapatalk
Click to expand...
Click to collapse
When you mount the sdcard is normal that doesn't mount again, the process hijack fsck_msdos, you have to come back to the application, wait and watch the window log.
It depends on mount will get 1-5 seconds to see the information.
If you see that init is OK, you can proceed with the get root.
{
"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"
}

jucaroba said:
Thanks for your answer.
I'm trying to use your exploit to be able to read my /data/misc/vold/expand_*.key file. My wife has a Moto G 2014 mobile with official (non rooted) Android 6 Marshmallow. The bootloader is locked. She has deleted accidentally all the pictures in her SD card, that is configured as adopted card (not portable). I have made a cloned copy of the SD in my linux laptop with dd command, but I can not mount the partitions in the SD because I have to know the encryption key.
I can not unlock the bootloader, because the phone will be reseted to factory and the encryption key will be deleted. And I can not read the key file without being root, because of the permissions of the file. I have tried your run-as-dirtycow trojan in the phone, and I can read files I have no permissions for, such as /init.rc. The only missing piece now is that I don't know the exact name of the key file. I only know that it is of the form "expand_*.key". Can your trojan run-as-dirtycow be modified to be able to read the files with this pattern name in a given directory?
Thanks in advance.
Click to expand...
Click to collapse
The run-as context can't see /data or even /data/misc folders, anyways i will implement the list of directories in the next update.

kryz said:
The run-as context can see /data or even /data/misc folders, anyways i will implement the list of directories in the next update.
Click to expand...
Click to collapse
Yes, I know it can see those folders, I only need to know the name of the file I am interested in.
If you implement the "list of directories" functionality it will be fantastic. Thanks for it.
I will also be very grateful to see the full source code of the trojan.
Waiting eagerly for both things.
Thanks in advance.

jucaroba said:
Yes, I know it can see those folders, I only need to know the name of the file I am interested in.
If you implement the "list of directories" functionality it will be fantastic. Thanks for it.
I will also be very grateful to see the full source code of the trojan.
Waiting eagerly for both things.
Thanks in advance.
Click to expand...
Click to collapse
Sorry wrong type i wanted to say that run-as context can not see those folders.
I mean ive implemented all ready that function "-d" and run-as can not list those folders:
run-as -d /system/etc
Attached run-as-dirtycow.c

kryz said:
Sorry wrong type i wanted to say that run-as context can not see those folders.
I mean ive implemented all ready that function and run-as can not list those folders.
Click to expand...
Click to collapse
Mmmm, so the only way to be able to read a file in /data/misc/vold/ is to be root?
If that is the case, then I suppose I have to wait til your exploit can be used to root a Marshmallow phone.
Am I correct?
Thanks.

jucaroba said:
Mmmm, so the only way to be able to read a file in /data/misc/vold/ is to be root?
If that is the case, then I suppose I have to wait til your exploit can be used to root a Marshmallow phone.
Am I correct?
Thanks.
Click to expand...
Click to collapse
I think so, i don't have that folder in my devices, but i was trying to read on /data folder and no success in one of its sub folders.
Btw what cpu is your device 32 o 64 bits?
Can you post your init file?

kryz said:
I think so, i don't have that folder in my devices, but i was trying to read on /data folder and no success in one of its sub folders.
Btw what cpu is your device 32 o 64 bits?
Can you post your init file?
Click to expand...
Click to collapse
My CPU is 32 bits. It is a Moto G 2014.
I suppose you don't have the /data/misc/vold folder because you are not looking at a Marshmallow system.
What file are you interested in? The /init.rc file?

jucaroba said:
My CPU is 32 bits. It is a Moto G 2014.
I suppose you don't have the /data/misc/vold folder because you are not looking at a Marshmallow system.
What file are you interested in? The /init.rc file?
Click to expand...
Click to collapse
I'm interested in /init file and 32 bits is great

kryz said:
I'm interested in /init file and 32 bits is great
Click to expand...
Click to collapse
No /init file in Marshmallow. At least not in that path.
---------- Post added at 02:19 AM ---------- Previous post was at 01:48 AM ----------
kryz said:
I'm interested in /init file and 32 bits is great
Click to expand...
Click to collapse
Sorry, the file exist, but I can not read it. I can not copy it with your trojan run-as (run-as-dirtycow) either.

Hi kryz,
Please find the /init from 32bit 6.0.1
It is from Xperia Z2 with custom rooted rom (Mx ROM v8.6.0)
How can i copy /init from my boot locked, unrooted, stock 6.0.1 64bit X Performance?

[CLOSED][SCRIPT][LINUX] Mount System as read write (Android 10+)

This Linux-only version is pretty much deprecated at this point. Please use the BRAND NEW UNIVERSAL VERSION instead! Thank you.
Ladies and gentlemen. Let me present to you my very first release here at the XDA forums:
Welcome to:
makeSystemRW v1.04
automated bash script by lebigmac for Android 10 and above​Creation date: February 2021
Updated: March 2021
Requirements:​
LINUX ONLY!
Android 10 or newer
This version only supports devices with super image.
Check if you have super by running ls -Alg /dev/block/by-name
phone must be rooted + bootloader unlocked + 10 GB free space on phone
at least 20 GB free space on computer for dumping data
adb and fastboot commands should be in your $PATH environment variable
I'm not 100% sure if this is a necessary requirement but I also disabled dm-verity and verification on my device just in case by simply booting into TWRP and then executing these 2 commands:
Code:
adb disable-verity
adb shell avbctl disable-verification
Description: A script for all Android power users that wish to make their read-only Android 10+ system read-write-able again to remove bloatware and make more thorough customizations to their device.
In a nutshell this is what the script is doing:
dumps your existing super image to your pc
extracts the embedded read-only partitions (system, vendor, product, etc...)
makes these partitions read-write-able
joins everything back together to new flashable super.img
flashes it to device
User data is not affected.
Usage: Simply call the script from the shell.
Optional arguments (replace x with your custom value) :
in=x : With this flag you can specify an existing super.img and skip the entire dumping of the super image process. Here you can use the super_original.img which you dumped earlier with makesysrw or the official super.img from your downloaded firmware. You probably have to unsparse the official super.img first using the included simg2img tool for superunpack to recognize it properly. If omitted, makesysrw will dump super image from phone to ./super_original.img
out=x : With this argument you can specify the output path. If omitted, default output value is ./super_fixed.img
size=x : With this parameter you can specify the extra free space (in megabytes) that will be added to each partition. If omitted, default extra size is 0 (shrink to minimum)
Examples:
Code:
# Run this command if you're first time user:
# Specify the extra free space in megabytes for each partition:
./makesysrw.sh size=100
# Plug an existing raw super image into the script like this:
./makesysrw.sh in=./super_original_raw.img size=100
# Specify both the input file as well as the output destination:
./makesysrw.sh in=./super_original_raw.img out=./super_fixed.img size=100
# For unsparsing the (sparse) super.img from your phone manufacturer's firmware you can do:
./tools/bin/simg2img ./super_sparse.img ./super_raw.img
NOTE: I did not come up with all this by myself. After searching for a solution for countless days without success, going even as far as learning hex editing - I coincidentally came across a couple of very interesting threads burried deep inside the new forum interface where this technique has been described and discussed by various enthousiasts (links can be found below in the credits section). So I take absolutely no credit for the underlying core mechanisms of the script. I'm only the amateur who put it all together into a compact script so that everybody can enjoy an Android system that's read-write-able again. Just like it used to be in Android 9 or earlier. Before this annoying 'shared_blocks feature' was implemented.
Credits: Big thanks to @munjeni for allowing me to use his amazing superunpack tool instead of the default lpunpack. Source code can be found here.
Also big thanks to @Brepro1 without your awesome tutorial guiding me I couldn't have created this script.
Thanks @AndyYan your interesting thread also helped me a lot for automating the script especially the lpdump part.
More thanks @gabrielfrias for his helpful comment
Thanks @YOisuPU and of course @topjohnwu for discovering the 'shared_blocks feature'
Thanks @bynarie for making available his otatools package! A part of it is now bundled with the archive
Disclaimer: This is open source software and is provided as is without any kind of warranty or support whatsoever. By using and viewing this software you agree to the following terms:
Under no circumstances shall the author be held responsible for any damages or negative consequences that may arrise from the (inappropriate) use of this software.
All responsibility and liability lies with the end-user. You hereby agree not to abuse this software for illegal purposes. Use this software at your own risk!
Please feel free to improve this script as you see fit (as long as you don't add anything malicious)
and make sure to post your feedback, suggestions and improvements in the official thread right here.
{
"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"
}
Mod Edit: Download link removed
Please click my like button below if you like it! Thanks​

It would be very helpful if you guys could please give me some feedback if the script works for you.
Which device are you using?
Your Android version?
Did you disable dm-verity and verification before running the script?
Your suggestions to enhance the script. Remember this is only version 1.0
Thanks!
@thor_1979

Great work! Your donation to the developers community is awesome.
The script works perfectly.
Consider keeping going.

Are you serious it actually works on your device? lmao
Congratulations. You are the first person to try it
The script pretty much does the same thing as your awesome tutorial describes.
Without your tutorial this script would not exist so thank you very much for making it available!

How do I use it? I'm really wanting to make my system rw again and this is perfect but how do I use it? It's a tar and Xz?

Simply extract the downloaded archive and open a terminal shell in the extracted folder by right clicking inside it and select Open in Terminal
Then run this command if you're running it for the first time
Code:
./makesysrw.sh size=100
or this command if you already have your raw super.img file
Code:
./makesysrw.sh in=./existing_super_image.img size=100
If you can't launch the script file make sure it is executable on your computer.

I really don't understand how this works why do you need the storage space is it making a system img that you than flash? I thought it just makes the current system read writable so you can install and uninstall system apps.

lebigmac said:
Simply extract the downloaded archive and open a terminal shell in the extracted folder by right clicking inside it and select Open in Terminal
Then run this command if you're running it for the first time
Code:
./makesysrw.sh
or this command if you already have your super.img file
Code:
./makesysrw.sh existing_super_image.img
If you can't launch the script file make sure it is executable on your computer.
Click to expand...
Click to collapse
Thanks I'm supposed to run the shell from my pc terminal or on the android device?

Sorry I see its for linux users. Ok now im getting it I have ubuntu 14 on my hard drive but I need to reinstall the grub menu because I deleted it or something. I have a s10 lite and tab S6 I would love to make the writable on the system so does this make a backup or dump of your system and than you flash it? Do you guys think thatll work on one ui 2.5 and im on lineage 18.1 on my s10 lite

Well in a nutshell this is what the script is doing:
dumps your existing super image to your pc
extracts the embedded read-only partitions (system, vendor, product, etc...)
makes these partitions read-write-able
joins everything back together to new flashable super.img
flashes it to device
User data is not affected.
The script is telling you exactly what's happening under the hood. You can also check out the source code if you have any doubts.
Yes this version of the script is supposed to be run on a Linux computer.
Please report back if it works for you or not.
Lineage OS? Doesn't that have a read-write-able system by default? In that case the script will likely fail.
Please keep in mind this script has been developed on Android 10 (Xiaomi X3 NFC) with a system that's read-only.

lebigmac said:
Well in a nutshell the script dumps your existing super image to your pc.
And then modifies the files to make everything read write able and then flashes back to the device. User data is not affected.
The script is telling you exactly what's happening under the hood. You can also check out the source code if you have any doubts.
Yes the script is supposed to be run on the computer
Please report back if it works for you or not.
Lineage OS? Doesn't that already come with read-write-able system by default? In that case the script will likely fail.
Please keep in mind this script has been developped on Android 10 MIUI 12 (Xiaomi X3 NFC) with a system that's read-only and embedded in a super image.
Click to expand...
Click to collapse
Honestly Im not a 100 percent sure anymore. I know it's a super img and it's really different in twrp there's a ton of new partitions and you have to wipe it off completely to flash a new system. I really haven't dug to deep into everything because I know that S6 oneui isn't writable and actually upset me because it's not like having full root access anymore.

For Windows users with TWRP.
(This is more like a reference)
From adb shell inside twrp.
X = Partition. To find out what block partition is mounted at, mount it in twrp then run 'df -h'.
e2fsck -f /dev/block/dm-x
resize2fs /dev/block/dm-x 3G
e2fsck -E unshare_blocks /dev/block/dm-x
Now reboot to fastbootd and execute:
fastboot resize-logical-partition <partition_slot> $((3*1024*1024*1024))

Thank you for the script.
When I read that I could use it with the super.img I guessed the usage was like
./makesysrw.sh image.img super_edited.img
I have a linux partition, but on a remote server and I was hoping to use it on the file and get my edited file from the server without putting the phone in the server..
Let me knowif you add something like that(-i and -o flags will be useful)
Best

Lossyx said:
For Windows users with TWRP.
(This is more like a reference)
From adb shell inside twrp.
X = Partition. To find out what block partition is mounted at, mount it in twrp then run 'df -h'.
e2fsck -f /dev/block/dm-x
resize2fs /dev/block/dm-x 3G
e2fsck -E unshare_blocks /dev/block/dm-x
Now reboot to fastbootd and execute:
fastboot resize-logical-partition <partition_slot> $((3*1024*1024*1024))
Click to expand...
Click to collapse
As much as I wish for a solution to be available to our fellow Windows users,
unfortunately your suggestion doesn't work here on my device see screenshot below.

lebigmac said:
As much as I wish for a solution to be available to our fellow Windows users,
unfortunately your suggestion doesn't work here on my device see screenshow below.
View attachment 5236719
Click to expand...
Click to collapse
Yeah. These dynamic partitions are weird, because for some reason I only managed to do this on slot A. And only did it on the vendor partition.
Also, this is the reference i was going by;
https://twitter.com/i/web/status/1260577424418488324

lebigmac said:
As much as I wish for a solution to be available to our fellow Windows users,
unfortunately your suggestion doesn't work here on my device see screenshow below.
View attachment 5236719
Click to expand...
Click to collapse
I think the problem is that you are requesting too large amount of memory try to replace 3G with smaller amount of memory

If anybody is good with creating flashable zips contact me! Need help working on universal version right now which will also be compatible with Windows and Mac users!
I am only amateur so need a real pro to give me some assistance here. Thank you.

Redmi note 9 pro. EU 12.0.2 rom. Android 10. It works. I installed WMware Workstation on a virtual machine in Windows. Thanks.(Google translate, sorry)

I can confirm that it works pềctly on my Pixel 4 XL Android 11 (coral-rq2a.210305.006) and Android 10 (coral-qq3a.200805.001), thank you for your awesome hard work!

Tried it on my Oneplus 7T Pro with Android 10. It extracted the superimage but failed at writing it back. It returned this error:
Code:
error: file_write: write: No space left on device
lpmake E 03-02 21:41:55 76867 76867 images.cpp:468] [liblp]sparse_file_write failed with code: -1
lpmake E 03-02 21:41:55 76867 76867 images.cpp:326] [liblp]Could not open image for partition: product_a
makesysrw: Error! failed to create super_fixed.img file./makesysrw.sh super_image.img 14.21s user 37.28s system 51% cpu 1:40.46 total
Any ideas? Thank you for your great work!

I need help rooting my zte quest 5

Ok so i got a zte quest 5 (z3351s) though qlink. Not the phone i wanted but it was one i could afford. And it works very well just can't run amazon music and other apps at the same time.
But the bloatware is unreal. Used to in my galaxy s3&s4 days i could root and delete all apps i didn't need. I know i can disable them but i want them gone completely.
Majisk didnt work
Kingoroot same even used pc.
I am hoping someone knows of a way i can root this phone or at least delete all the un needed apps for example i have Google maps go (came stock) i put the org google maps which is better plus offers sat view.
Edit i did some math and converting and the useless apps 11 out of 58 come out to 349.72mb which is a lot if your phone only has 16gb of space. Also note i don't have hardly anything.
Worst case i can Hotspot to my note10+ for multitasking but not sure of data limit.

@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.

I heard about adb methods but i haven't messed with it in forever since apk/ios apps came out

jwoegerbauer said:
@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.
Click to expand...
Click to collapse
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.

vp1117 said:
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.
Click to expand...
Click to collapse
I spoke of SU-binary and NOT of SuperSU installer package
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.

TexasPride, sorry I stepped in your thread.​
jwoegerbauer said:
I spoke of SU-binary and NOT of SuperSU installer package
Click to expand...
Click to collapse
I see. It is often mixed in numerous materials one can find in the net. Subject is SU-binary update, but the ultimate goal is to install supersu.
jwoegerbauer said:
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Click to expand...
Click to collapse
What should be result of running this code? SU-binary located in Downloads with 777 permission? What is the practical sense/use of it?
What software/application would use SU in that location?
Sorry for my questions. I'm not arguing. I try to understand the idea.
jwoegerbauer said:
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.
Click to expand...
Click to collapse
Somehow, with my almost zero knowledge of edify and linux command line I got the same conclusion: SuperSU zip has to be modified in order to install it via adb on devices that do not have TWRP for sideload. I failed to find any examples of SuperSU modding...

@vp1117
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
{
"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"
}
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"

jwoegerbauer said:
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
Click to expand...
Click to collapse
OK. I guess, I can repack zip to tar.
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
jwoegerbauer said:
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"
Click to expand...
Click to collapse
Interestingly, I can execute all commands I need without having su-binary (~100 KB) uploaded to my phone. It is strange but I see #-prompt after I ran <adb shell>. This happens on my UNrooted phone, running stock ROM. I guess, it's a specifics of my phone, no need to try explain it.

I done failed trying to read i dont really understand linux all that well. But if anyone has any links so i can download it and try it

vp1117 said:
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
Click to expand...
Click to collapse
Of course it's your decision how you transfer the SuperSU package onto phone: many ways lead to Rome.
My decision was to push SuperSU package repacked as TAR-file onto phone, extract it there, and finally run the modified update-binary.sh when phone is booted into recovery mode:
Code:
adb shell "$(cat < %supersu_dir%/update-binary.sh); echo $?"

So I rebooted to stock recovery and then uploaded following from UPDATE-SuperSU-v2.82-20170528234214.zip package to my phone's folder /tmp:
/arm64
/common
/META-INF
update-binary.sh
Here is what I got:
Z:\android\adb>adb shell "$(cat < /tmp/update-binary.sh); echo $?"
127
/system/bin/sh: #!/sbin/sh: not found
And here's what I got running same command from # command line:
# $(cat < /tmp/update-binary.sh); echo $?
/system/bin/sh: #!/sbin/sh: not found
127
In response to # ls -al /sbin I get lots of lines one of them is as follows:
lrwxrwxrwx 1 root root 7 1970-01-01 00:00 sh -> busybox
I feel that I'm doing something wrong, but what exactly?
In attached txt-file I put some more details I got in command line.

jwoegerbauer said:
... and finally run the modified update-binary.sh when phone is booted into recovery mode:
Click to expand...
Click to collapse
Am I right the only modification needed is to rename update-binary to update-binary.sh ?

@vp1117
NO.
When I said modified then I didn't mean simply rename it: The contents of original update-binary file must be rewritten / deleted in some parts. Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above. Take also note that, if device's Android isn't rooted yet, the location for unpacked SuperSU mandatory must be /data/local/tmp.
BTW:
I can see BusyBox is installed on your device's Android. Take note that BusyBox by default comes with the SU-binary. Hence your device's Android is rooted! Wondering why you waste your time with trying to completely install SuperSU from scratch?

jwoegerbauer said:
Wondering why you waste your time with trying to completely install SuperSU from scratch?
Click to expand...
Click to collapse
Good question.
Probably, because I see this when phone restarts from recovery to normal android:

jwoegerbauer said:
Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above.
Click to expand...
Click to collapse
OK, no problem, I can re-pack zip into tar.
However, what you demonstrated above was a screenshot showing update-binary.sh being inside the tar. At the same time you don't tell how update-binary.sh must be amended. Is it OK?

TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.

vp1117 said:
TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.
Click to expand...
Click to collapse
Its ok, i dont mind at all.

@TexasPride
FYI: I no longer participate this hijacked thread.

What does "the su binary is out of date " actually mean? Is there a way to manually fix this?

Quick background: I want to start fresh with my Nook Tablet and leave out GApps this time, opting for microG instead. I'm familiar with all that entails and have done it on other devices.
The problem, in a nutshell: After wiping and reflashing the custom AOSP 7.0 ROM, I flash a small zip which contains and places the su binary (as far as I understand). Then I reboot and install a Superuser control app. I get "the su binary is out of date" message and do not have root.
I am following my own instructions from here when I first flashed the ROM with GApps. But now they don't work! Later in that thread a few people express problems with the same thing.
So...what does this "out of date" business actually mean? Is there a "use by" date on the su or something? That seems unlikely. I've tried all kinds of orders of operation with this thing but keep coming up with the same result. Searching around on line I can't seem to find any sort of explanation, just a lot of schemes, many dubious.
I've looked at SuperSU zip packages, but every one I try seems to be wanting system-less root and there is no way I know to unlock the bootloader.
I know that Magisk exists, but have never gotten into using it. I'd rather not, if possibe. I just don't see why something that worked a few years ago does not work now. It's not like it needs to contact a remote source for information.
As a last resort I could return to a backup and try to manually remove GApps but I'd really rather start with a clean ROM install and go from there. I need root to do what I want or I wouldn't bother with any of this.
Suggestions, explanations?

Uninstall / delete SuperSU app.
FYI:
The SU binary is a Android shell command typically incorporated in Toybox, the Linux commands suite merged with Android since its version 6, but left off by almost all OEMs - for good reasons.
The SU binary is available as standalone cmdlet at various locations in Internet. It also comes with Magisk.

every rooting solution's su binary is different from traditional linux su.
it simply means the su binary does not fit the Superuser app. according to support thread you still can grant root and just update su binary straight from within the app (won't work with foreign su)
https://forum.xda-developers.com/t/...linux-capable-superuser.3216394/post-64823952

aIecxs said:
every rooting solution's su binary is different from traditional linux su.
it simply means the su binary does not fit the Superuser app. according to support thread you still can grant root and just update su binary straight from within the app (won't work with foreign su)
https://forum.xda-developers.com/t/...linux-capable-superuser.3216394/post-64823952
Click to expand...
Click to collapse
Yeah, but it (the apk) doesn't do anything. And the links in the thread you reference to updated zips, etc., all give 403 errors.
I "understand" the concept of matching the su binary with the superuser controller app, but I can't see how a combination that once worked now does not. That's what is frustrating. Like it's magic.

most likely there is a foreign leftover su (chainfire's SuperSU or something else?) which is not granting access to phhusson's Superuser.

aIecxs said:
most likely there is a foreign leftover su (chainfire's SuperSU or something else?) which is not granting access to phhusson's Superuser.
Click to expand...
Click to collapse
Could be. A TWRP examination of /system/bin shows no sign of su (no wonder it needs "updating"). Meanwhile, /system/superuser is chock full of SuperSU stuff and the phh stuff, including a copy of su. So clear all that out and start again.
I guess I need to check if su is actually placed in /system/bin after flashing the zip package. Otherwise...maybe just put it there myself?

afaik all custom binaries belong to /system/xbin which is also in path. what's wrong with systemless-root in boot?
latest official SR3-SuperSU-v2.79-SR3-20170114223742.zip by Chainfire is capable of.

aIecxs said:
afaik all custom binaries belong to /system/xbin which is also in path. what's wrong with systemless-root in boot?
latest official SR3-SuperSU-v2.79-SR3-20170114223742.zip by Chainfire is capable of.
Click to expand...
Click to collapse
Before flashing the su zip there is an su already present in /system/xbin. After flashing, there is also an su present in /system/bin. And yes, I wiped thoroughly (twice).
I was surprised at the su already in /system/xbin. Out of curiosity I booted up another tablet running CM 13. It, too contains su in both locations, but the dates on the files are very different. The one in /system/bin is today's date, while the one in /system/xbin is sometime back in 2009 (like when the ROM was perhaps cooked up). Turns out even my ancient Nook Simple Touch (which is rooted) has an su in both locations.
Anyway, I see there is clearly an su newly placed in /system/bin now that I've flashed the su zip package. So it should work when the controller app is installed...
None of the Chainfire zips I have tried will work. They all seem to want the bootloader unlocked and so each one fails.

you can flash modified system on locked bootloader? Now you have root and TWRP, I guess bootloader is unlockable. I bet @AdamOutler can. at least, another guy managed it obviously...
https://forum.xda-developers.com/t/barnes-noble-nook-tablet-10-1-bntv650-working.3873476

aIecxs said:
every rooting solution's su binary is different from traditional linux su.
Click to expand...
Click to collapse
Wrong, as so often:
1. The su ( read: Substitute User ) shell command allows users to become other users. This command is thought to escalate privileges by becoming a privileged user; therefore, the default user is the root if no user-id is specified.
2. This is true for su shell command as it comes with Linux and/or Android ( where su since Android version 6 is included in Toybox command suite - and su might also be integral part of 3rd-party Linux commands suite named BusyBox )
3. All 3 mentioned su shell commands equally allows users to become other users. With no arguments passed, USER is root. Only difference is the way and order arguments get passed to su.

@jwoegerbauer you have no clue what you're talking about. I have already tried to explain you here, furthermore I have proofed you wrong there (your linked binaries were not even build with -fPIE)
I get the feeling you don't even know what a Superuser app actually is.

To my knowledge SuperUser app is predecessor of Magisk Manager app.

yes, Magisk app also includes Superuser app (second tab on bottom). how is that related to my question? Did you finally read about what su daemon is, and how the Superuser app grants requesting apps to hook up to daemon?
or do you still insist every Superuser app can just work with every su, or root access can be achieved by just toybox su (like linux su)? if so, please link the toybox used for, so I can test it myself.

I'm surprised that you're not able to find Toybox on the Internet, but you expect a link from me.
I'm also surprised that you obviously take pleasure in disparaging others here if they don't think or act as you do.
BTW:
When I'm mentioning SU at XDA threads, then I really mean the SU binary itself - as it's well known from Linux - and NOT the supersu daemon, what grant root to apps, as you do. Why exactly do one need an app to have root permissions? To enter protected user-space?

I have asked clear question, please tell us which toybox or su binary will work for getting root shell.
where shoud I place it? what permissions should I set, and how?
Spoiler
official toybox
{
"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"
}
BTW:
wasn't it you the one who called me an idiot two times when confronted with your false claims?

You have used the NON-ROOT version of Toybox.
The full version of Toybox you find here:
Index of /toybox/downloads/binaries
It's on you to replace the mangled Toybox version with the full version: shouldn't be too difficult for an Android guru as you are.

First, this toybox is missing important applets without android smartphone wouldn't work properly anymore. That's why one must not replace toybox.
second, you still haven't answered the question which location and permissions one must set.