Related
Disclaimer 1 : I tried to look for something like this but I did not found it. Then I tried to achieve it. Sorry if they are well known steps
This guide allows to root a Nexus One with unlocked bootloader with NO need to flash recovery
USE THAT INFORMATION AT YOUR RISK!!
Updated: Added a line to work with Gingerbread
That steps are for Ubuntu. If you are any interested windows user, please let me know.
Prerequisites:
Unlocked bootloader
adb working properly
1. Download fastboot
Code:
wget --referer=http://developer.htc.com/adp.html http://dl4.htc.com/RomCode/ADP/fastboot.zip
unzip fastboot.zip
chmod u+x fastboot
rm fastboot.zip
2. Obtain busybox (anyone have any direct link?) - NOT GOING TO FLASH CM, JUST GETTING busybox from a trusted place
Code:
wget http://download.cyanogenmod.com/get/update-cm-7.0.0-N1-signed.zip
unzip update-cm-7.0.0-N1-signed.zip system/xbin/busybox
rm update-cm-7.0.0-N1-signed.zip
3. Download su
-- UPDATE: that link broken, you have to donwload it from Google Play
Code:
wget http://dl.dropbox.com/u/6408470/su-releases/su-2.3.6.1-ef-signed.zip
unzip su-2.3.6.1-ef-signed.zip system/app/Superuser.apk system/bin/su
rm su-2.3.6.1-ef-signed.zip
4. Download recovery-RA - NOT GOING TO FLASH IT, DON'T WORRY!!!
Code:
wget -O recovery-RA-passion-v2.2.1.img http://files.androidspin.com/files/amon_ra/RECOVERY/recovery-RA-passion-v2.2.1.img
md5sum recovery-RA-passion-v2.2.1.img
echo ... Validate md5sum is 3def709ab1c9e051a92a1c8b1504a36a
5. Reboot to bootloader - JUST BOOTING WITH, NO FLASHING
Code:
adb devices
adb wait-for-device
adb reboot-bootloader
fastboot boot recovery-RA-passion-v2.2.1.img
echo ... Waiting for recovery image load
while [ -z `adb shell pwd 2> /dev/null` ]
do
sleep 1
done
6. Root it!
Code:
adb shell mount /system
adb push system/xbin/busybox /system/bin/busybox
adb shell chmod 4755 /system/bin/busybox
adb push system/bin/su /system/bin/su
adb shell chmod 4755 /system/bin/su
adb push system/app/Superuser.apk /system/app/Superuser.apk
adb shell chmod 4755 /system/app/Superuser.apk
7. Reboot and enjoy rooting
Code:
adb shell reboot
Will this work on stock Gingerbread?
If you are running Nexus One with Gingerbread, as I understand, it can work. I've not tried, you can try.... at your risk ;-)
Helleqn said:
Will this work on stock Gingerbread?
Click to expand...
Click to collapse
If you have an unlocked bootloader, yes, it will work. If you have an unlocked bootloader, you can install pretty much anything you want, whenever you want...
Sent from my Nexus One using XDA Premium App
Helleqn said:
Will this work on stock Gingerbread?
Click to expand...
Click to collapse
I've added a adb command (mount /system) to work with Gingerbread. It works on mine.
It also works on 2.3.4
Yep. Worked great for me. But with all due respect, it seemed a little fishy to me that your directions have users pull busybox from Cyanogenmod but then have them pull su and Superuser.apk from a random file on a Dropbox account especially since both files are available in the already trusted Cyanogenmod download that was used for busybox. And even more so because the Superuser.apk file using your instructions is a larger file than the one included with Cyanogenmod. So I only used the files from CM and it worked like a charm.
Not accusing you or anything. I'm just pointing that out.
The easier way is to do step 5, then flash the su zip from step 3, and you're pretty much done. You can install busybox through the Market app...
Don't worry for the link, I toke it from the original post for that su release:
http://forum.xda-developers.com/showthread.php?t=682828
I agree it's enough with CM but I intend to get the last version... may be it's not the best option...
Thanks for your comments.
HI, The latest version of stock firmware for galaxy mini is MJKT3, now how do I root it?
http://www.mediafire.com/?p0oh96olw9h2v72
hi
this will root all versions even the latest one? or like released by 1 minute? or new ones that has been released 1-10 seconds ago?
just try it if it worked just thank me and the Dev of the update package
if not do something else
I forgot to tell you that you will need to flash that package in stock recovery (in CWM it will not work)
It doesn't work.
it doesn't work for me too
super one click can't be used too
Flash this zip in stock recovery. http://www.mediafire.com/?dg360wy61szduv3
Sent from my SGM using Official Cyanogenmod 7.2 (STABLE)
i did flash it
---------- Post added at 06:42 AM ---------- Previous post was at 06:14 AM ----------
can
ashu.bigsmoke said:
Flash this zip in stock recovery. http://www.mediafire.com/?dg360wy61szduv3
Sent from my SGM using Official Cyanogenmod 7.2 (STABLE)
Click to expand...
Click to collapse
can someone tell me if this one will work?
17thGwydion said:
can someone tell me if this one will work?
Click to expand...
Click to collapse
no
I did try another .zip but not succeeded, it just installed super user
you can flash cwm then with the help of adb you can remount system and can push su to /system
tut
dheeraj (dhlalit11) said:
you can flash cwm then with the help of adb you can remount system and can push su to /system
Click to expand...
Click to collapse
can u give me a tutorial on how to push SU to system? or remount system? or full tutorial.. thanks
full tut plz
still no good
still no good feedback, someone try it please
flash cwm with odin
boot into it
connect your mobile with pc
configure your adb connection correctly
open cmd cd to the folder where you are having adb.exe file
copy your su file in the folder where you have adb
type adb remount
adb push su /system/xbin
adb shell chmod 06755 /system/xbin/su
adb shell
if you will get # you are rooted
Can't set SetUID or SetGID bit.
adb shell chmod 06755 /system/xbin/su
"chmod: operation not permitted"
SuperOneClick doesn't work also.
/system partition is 100% full, you have to delete something to push su binary. (i deleted stock samsung apps, and wallpapers)
dheeraj (dhlalit11) said:
flash cwm with odin
boot into it
connect your mobile with pc
configure your adb connection correctly
open cmd cd to the folder where you are having adb.exe file
copy your su file in the folder where you have adb
type adb remount
adb push su /system/xbin
adb shell chmod 06755 /system/xbin/su
adb shell
if you will get # you are rooted
Click to expand...
Click to collapse
you were able to push su which means you have proper access
my be permission change is not needed
try type adb shell su
or use aroma file manager v1.80 and change su permission from that
Unfortunately permission change is a must. You must set setuid and setgid (06755), because upon the su binary execution it will pass the owner's (root) permissions.
Can't use aroma file manager to set permissions because /system/xbin/su owner is root and a plain user can't change permission on files that he doesn't own.
I don't know how to solve this issue.
edit:
I can mount the system partition as rfs:
mount -rw -t rfs /dev/block/stl12 /system
Then, i can set chmod 06755 su.
But after unmount or reboot, permission will be set back to 00755...
dheeraj (dhlalit11) said:
you were able to push su which means you have proper access
my be permission change is not needed
try type adb shell su
or use aroma file manager v1.80 and change su permission from that
Click to expand...
Click to collapse
it is too much weird
can you use linux
you may be able to change the permission of the su file in Linux desktop and then can push it to system with adb
in this way permissions would remain same
Ok, it's solved!
I tried with ubuntu's adb. Unpacked the universal_gb_root_v25.zip. I mounted the system partition in adb. Then pushed all files with correct permissions to /system/xbin (the apks goes to /system/app).
First:
chown all files to root:shell
Second:
chmod 06755 /system/xbin/su
chmod 04755 /system/xbin/busybox
chmod 04755 /system/xbin/sqlite3
chmod 04755 /system/xbin/ssh
now it looks like this:
-rwsr-xr-x 1 root shell 853044 Jun 22 2011 busybox
-rwxr-xr-x 1 root shell 60264 Dec 6 10:28 dexdump
-rwsr-xr-x 1 root shell 125024 Jun 22 2011 sqlite3
-rwsr-xr-x 1 root shell 146720 Jun 22 2011 ssh
-rwsr-sr-x 1 root shell 91980 Jun 22 2011 su
It works after unmount or reboot.
Finally i have root access.
dheeraj (dhlalit11) said:
it is too much weird
can you use linux
you may be able to change the permission of the su file in Linux desktop and then can push it to system with adb
in this way permissions would remain same
Click to expand...
Click to collapse
Has anybody worked out how to create a Genymotion Xposed testing device?
What I've already achieved:
- Grant Root access to Xposed
- Flash ARM zip
The problem is: Genymotion runs on x86, not ARM. So flashing the ARM zip just breaks the VM.
But flashing the x86 zip just gives the Error "Failed to flash file".
(Yes, I'm using Genyflash)
I also tried it with and without arm translation, no changes.
I simply have no idea what else I could try. Is it currently possible at all?
LM13 said:
Has anybody worked out how to create a Genymotion Xposed testing device?
What I've already achieved:
- Grant Root access to Xposed
- Flash ARM zip
The problem is: Genymotion runs on x86, not ARM. So flashing the ARM zip just breaks the VM.
But flashing the x86 zip just gives the Error "Failed to flash file".
(Yes, I'm using Genyflash)
I also tried it with and without arm translation, no changes.
I simply have no idea what else I could try. Is it currently possible at all?
Click to expand...
Click to collapse
I found that the flash-script.sh inside the xposed-v78-sdk23-x86.zip file is somehow not successfully executed by Genymotion. I've manually patched it.
getting root on Marshmallow
Hi,
How did You get root on Marshmallow?
Sergiusz
sbrzezin said:
Hi,
How did You get root on Marshmallow?
Sergiusz
Click to expand...
Click to collapse
Yes, the latest Genymotion version already come with rooted MM image
itandy said:
Yes, the latest Genymotion version already come with rooted MM image
Click to expand...
Click to collapse
I installed Custom Phone and Google Nexus 7 and none of them has root. Should I do any special setup or did I install wrong device? I use Genymotion 2.6.0 free version.
Sergiusz
sbrzezin said:
I installed Custom Phone and Google Nexus 7 and none of them has root. Should I do any special setup or did I install wrong device? I use Genymotion 2.6.0 free version.
Sergiusz
Click to expand...
Click to collapse
The ROM should be rooted already. su command is available and when you use ADB, it's already a rooted shell.
itandy said:
The ROM should be rooted already. su command is available and when you use ADB, it's already a rooted shell.
Click to expand...
Click to collapse
I got answer from Genymotion team:
"I just got an update from the Dev Team : it appears that in 6.0 the SuperUser Android App hasn't been yet implemented.
This feature will be implemented in the future, and I have linked your request to the task.
When it will be completed and released, you will be automatically notified."
Sergiusz
sbrzezin said:
I got answer from Genymotion team:
"I just got an update from the Dev Team : it appears that in 6.0 the SuperUser Android App hasn't been yet implemented.
This feature will be implemented in the future, and I have linked your request to the task.
When it will be completed and released, you will be automatically notified."
Sergiusz
Click to expand...
Click to collapse
So I managed to make some progress on this. I got the latest v84 xposed working in the newest Genymotion 2.6.0 with a Nexus 5X image by doing the following:
Code:
git clone https://github.com/rovo89/GenyFlash
cd GenyFlash && ./install.sh
adb push xposed-v84-sdk23-x86.zip /sdcard
adb shell flash-archive.sh /sdcard/xposed-v84-sdk23-x86.zip
Reboot Genymotion VM and then drag XposedInstaller_3.0_alpha4.apk to Genymotion vm...profit!
As stated above, the Genymotion images are rooted but a lot of root apps ask for permission and the prompt to grant/deny root wasn't working for me rendering the apps limited in use. I downloaded the newest SuperSU BETA, at the time of this post, BETA-SuperSU-v2.71-20160331103524. I extracted it and then issues the following commands from terminal:
Code:
adb shell mount -o remount,rw /system
adb install common/Superuser.apk
adb push x86/su /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push x86/su /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb shell setenforce 0
adb shell mount -o remount,ro /system
The problem was issuing the "su" commands resulted in: "error: only position independent executables (PIE) are supported." Countless time spent google searching didn't turn up any leads, but then I happened to notice in the x86/su directory a file called su.pie...pie = position independent executable derp. So I reran the following:
Code:
adb shell mount -o remount,rw /system
adb push x86/su.pie /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push x86/su.pie /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb shell setenforce 0
adb shell mount -o remount,ro /system
Rebooted my Genymotion vm and BAM root access prompts!!!!! Hope this helps others and good luck.
Worked for me
123SIT said:
So I managed to make some progress on this. I got the latest v84 xposed working in the newest Genymotion 2.6.0 with a Nexus 5X image by doing the following:
Code:
git clone https://github.com/rovo89/GenyFlash
cd GenyFlash && ./install.sh
adb push xposed-v84-sdk23-x86.zip /sdcard
adb shell flash-archive.sh /sdcard/xposed-v84-sdk23-x86.zip
Reboot Genymotion VM and then drag XposedInstaller_3.0_alpha4.apk to Genymotion vm...profit!
As stated above, the Genymotion images are rooted but a lot of root apps ask for permission and the prompt to grant/deny root wasn't working for me rendering the apps limited in use. I downloaded the newest SuperSU BETA, at the time of this post, BETA-SuperSU-v2.71-20160331103524. I extracted it and then issues the following commands from terminal:
Code:
adb shell mount -o remount,rw /system
adb install common/Superuser.apk
adb push x86/su /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push x86/su /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb shell setenforce 0
adb shell mount -o remount,ro /system
The problem was issuing the "su" commands resulted in: "error: only position independent executables (PIE) are supported." Countless time spent google searching didn't turn up any leads, but then I happened to notice in the x86/su directory a file called su.pie...pie = position independent executable derp. So I reran the following:
Code:
adb shell mount -o remount,rw /system
adb push x86/su.pie /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push x86/su.pie /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb shell setenforce 0
adb shell mount -o remount,ro /system
Rebooted my Genymotion vm and BAM root access prompts!!!!! Hope this helps others and good luck.
Click to expand...
Click to collapse
Worked for me on the Google Nexus 9 API 23
gamerkcw123 said:
Worked for me on the Google Nexus 9 API 23
Click to expand...
Click to collapse
Hell yeah! I was beginning to think I was the only one who wanted this...and then there were two lol
123SIT said:
Hell yeah! I was beginning to think I was the only one who wanted this...and then there were two lol
Click to expand...
Click to collapse
the Supersu.apk still won't update the su binary. Do you know of a way to get that to work? If not I don't care I have supersu granting root. LOL
gamerkcw123 said:
the Supersu.apk still won't update the su binary. Do you know of a way to get that to work? If not I don't care I have supersu granting root. LOL
Click to expand...
Click to collapse
If I remember correctly I have that same issue but if you use the newest supersu zip you should be able to update it manually via the provided steps.
I think GenyFlash shouldn't be needed anymore... just drag and drop the x86 zip and the installer APK on the Genymotion window and reboot. The only thing that isn't working are the reboot buttons in the installer.
123SIT said:
If I remember correctly I have that same issue but if you use the newest supersu zip you should be able to update it manually via the provided steps.
Click to expand...
Click to collapse
I got it to work. This is what I did. I fallowed your steps to get SuperSU working, and granting
apps permission. Then I removed the APK and installed the APK from the 2.46 update. Then I updated SuperSU.apk from the play store. Success the binary updated successfully.
Step 1: fallowed your steps with the Bata.
Step 2: once I confirmed superSU is working, I remove the APK.
Step 3: I use the SuperSU APK in the 2.46 update.
Step 4: I use adb to push the APK in the 2.46 update to /system/app, and chmod it to 755.
Step 5: I reboot and go to the play store and update SuperSU.
Success!!!!!!!
this was again on the Genymotion Google Nexus 9 6.0 API.
rovo89 said:
I think GenyFlash shouldn't be needed anymore... just drag and drop the x86 zip and the installer APK on the Genymotion window and reboot. The only thing that isn't working are the reboot buttons in the installer.
Click to expand...
Click to collapse
You know, I don't think I ever actually tried it without. May have saved me some time lol
123SIT said:
So I managed to make some progress on this. I got the latest v84 xposed working in the newest Genymotion 2.6.0 with a Nexus 5X image by doing the following:
Code:
git clone https://github.com/rovo89/GenyFlash
cd GenyFlash && ./install.sh
adb push xposed-v84-sdk23-x86.zip /sdcard
adb shell flash-archive.sh /sdcard/xposed-v84-sdk23-x86.zip
Reboot Genymotion VM and then drag XposedInstaller_3.0_alpha4.apk to Genymotion vm...profit!
As stated above, the Genymotion images are rooted but a lot of root apps ask for permission and the prompt to grant/deny root wasn't working for me rendering the apps limited in use. I downloaded the newest SuperSU BETA, at the time of this post, BETA-SuperSU-v2.71-20160331103524. I extracted it and then issues the following commands from terminal:
Code:
adb shell mount -o remount,rw /system
adb install common/Superuser.apk
adb push x86/su /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push x86/su /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb shell setenforce 0
adb shell mount -o remount,ro /system
The problem was issuing the "su" commands resulted in: "error: only position independent executables (PIE) are supported." Countless time spent google searching didn't turn up any leads, but then I happened to notice in the x86/su directory a file called su.pie...pie = position independent executable derp. So I reran the following:
Code:
adb shell mount -o remount,rw /system
adb push x86/su.pie /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push x86/su.pie /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb shell setenforce 0
adb shell mount -o remount,ro /system
Rebooted my Genymotion vm and BAM root access prompts!!!!! Hope this helps others and good luck.
Click to expand...
Click to collapse
It's worked on Galaxy S6 6.0.0 API23, Genymotion 2.7.2! Thanks you so much!
I am in the position of having to manually apply the defult sepolicy patch, init,?*init_shell?* and?*recovery?*permissive, and as the title states when using the supolicy tool to modify my supplieded sepolicy it is not being produced and on closer inspection throwing an error. I have attached both the images and the sepolicy file I am trying to applie these change to.
Have I been doing something wrong or is the file corrupted??
If you need more info just ask
Note: when I first tried it inside an adb shell it reported a segumentation fault, but I was unable to reproduce that condition to be provided with as a screen shot.
{
"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"
}
EDIT: I at least can say that the possibility of a corrupt file is now smaller becuse I am able to run dumpav and dump its contents to a txt file and then do afb pull back to pc. So amyone know any way to applie the defult P atchs needed to sysyemless root?
@Chainfire Since this is your binary files, you should know the most about it.
Commands to gain application root on emulator
Code:
adb shell df #Check Available Space
adb shell mount -o remount,rw /system
adb push su /system/bin/su
adb shell chmod 0755 /system/bin/su
adb push su /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb shell su --install
adb shell "su --daemon&"
adb install superuser.apk
adb install rootcheck.apk
I then proceed to patch the sepolicy file with the following commands
Code:
adb push sepolicy /data/local/tmp/sepolicy
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out" #There is no sepolicy_out file
adb shell su -c "chmod 0644 /data/local/tmp/sepolicy_out"
adb pull /data/local/tmp/sepolicy_out sepolicy_out
So what am I able to do?
Are you able to
A) Help me debug the problem
Or
B) Patch the sepolicy file and post the output back to me/here
Matt07211 said:
...
Click to expand...
Click to collapse
Works fine on my device... could be an x86 specific issue? Unfortunately I don't have any x86 devices to test with.
Thanks for that. Yes, I am trying to patch the policy for my armv8 (arm64) cpu device (just realised, but would trying to patch the sepolicy from one architecture using the supolicy for a different architecture have new the problem?, if so I feel dumb). And since I didn't have a spare device devce that met the requirements, I resorted to use the already setup emulator in my Windows installation.
I had proceeded to root and run the supolicy tool for which nothing out-putted (tried different directorys), I then created a new sub-directory, test, in /data/local/tmp and chmod it with read and write permissions. I tried again and failed, I then ran a dumpav in the sepolicy I was trying to patch and outputted it to /data/local/tmp/test/dumpav.txt which worked.
I am just wondering why it didn't work for me .
Thanks again for the sepolic_out file, I really do apperciate it.
Ah you're saying the segmentation fault occurred on the emulator? That's interesting. Might be reproducable on my end.
Note: look at my first image with cms in the foreground and near the bottom of the command window you should see the segfault message, around second last command or so.
To reproduce that segfault (hopefully):
1) https://software.intel.com/en-us/android/articles/android-44-kitkat-x86-emulator-system-image Download the system image from here (had to direct download instead of sdk as internet was running through profile and ask wouldn't work through it)
2) used the 2.78 SuperSu zip and run above commands to gain root
3) run above commands to try and modify sepolicy (it doesn't produce anything)
4) start an adb shell and then run the commands inside the shell. Know the outputs shown was segfault the first time running the commands, every time afterwards it would show the error in the above screenshots
If you figure out what cause the segfault can you please tell me ?
Matt07211 said:
Note: look at my first image with cms in the foreground and near the bottom of the command window you should see the segfault message, around second last command or so.
To reproduce that segfault (hopefully):
1) https://software.intel.com/en-us/android/articles/android-44-kitkat-x86-emulator-system-image Download the system image from here (had to direct download instead of sdk as internet was running through profile and ask wouldn't work through it)
2) used the 2.78 SuperSu zip and run above commands to gain root
3) run above commands to try and modify sepolicy (it doesn't produce anything)
4) start an adb shell and then run the commands inside the shell. Know the outputs shown was segfault the first time running the commands, every time afterwards it would show the error in the above screenshots
If you figure out what cause the segfault can you please tell me ?
Click to expand...
Click to collapse
Before I go do all this, can you make sure the issue persists with the v2.78 SR1 version from the BETA thread ? Some issues with supolicy were fixed in that release.
Started with a fresh emulator and the newest SuperSu and ran these commands to gain root (I am placing everything as described in update-binary in the right places just to eliminate one thing, missing dependencies)
Code:
adb shell df
adb shell mount -o remount,rw /system
adb push Superuser.apk /system/app/Superuser.apk
adb shell chmod 0644 /system/app/Superuser.apk
adb push install-recovery.sh /system/etc/install-recovery.sh
adb shell ln -s /system/etc/install-recovery.sh /system/bin/install-recovery.sh
adb shell chmod 0755 /system/etc/install-recovery.sh
adb push su /system/xbin/su
adb shell chmod 0755 /system/xbin/su
adb push su /system/bin/.ext/.su
adb shell chmod 0755 /system/bin/.ext/.su
adb push su /system/xbin/daemonsu
adb shell chmod 0755 /system/xbin/daemonsu
adb push su /system/xbin/sugote
adb shell chmod 0755 /system/xbin/sugote
adb push supolicy /system/xbin/supolicy
adb shell chmod 0755 /system/xbin/supolicy
adb push libsupol.so /system/lib/libsupol.so
adb shell chmod 0644 /system/lib/libsupol.so
adb push 99SuperSUDaemon /system/etc/init.d/99SuperSUDaemon
adb shell chmod 0755 /system/etc/init.d/99SuperSUDaemon
adb shell su --install
adb shell "su --daemon&"
adb install superuser.apk
adb install rootcheck.apk
No everything should be in place, and we now can eliminate one thing (supolicy not finding needed dependencies)
Opened up SuperSu and let it install/update binary (succesful)
I then proceeded to patch the sepolicy file like so
Code:
adb push sepolicy /data/local/tmp/sepolicy
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out"
I then did "ls" in the directory and no file out-putted. So I went into a shell and ran
Code:
supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out
And it throw the error shown in the image below. First time running that command in shell it says stopped, but the second time it says stopped as well as segfault.
Keep in mind I am trying to patch a sepolicy file that originates from an armv8 cpu (arm64) on an x86 Intel emulator.
Any more info needed? I am happy to help @Chainfire
So, I think it has something to do with your emulator image (perhaps its too old ?)
I took SuperSU's ZIP file and extracted it, changed to that folder, then:
(note that my adb shell to my emulator image has # root by default)
Code:
adb push c:\download\sepolicy /data/local/tmp/sepolicy
adb push x86\. /data/local/tmp/.
adb shell
cd /data/local/tmp
chmod 0755 supolicy
LD_LIBRARY_PATH=/data/local/tmp:$LD_LIBRARY_PATH ./supolicy --file sepolicy sepolicy_out
exit
Resulting in:
Code:
supolicy v2.78 (ndk:x86) - Copyright (C) 2014-2016 - Chainfire
Patching policy [sepolicy] --> [sepolicy_out] ...
- Success
So, I'm really not sure what might be going on with your setup, but I don't think its SuperSU itself, but rather the emulator.
Note that to use supolicy --file, you only need supolicy and libsupol.so, you don't even need root.
Chainfire said:
So, I think it has something to do with your emulator image (perhaps its too old ?)
I took SuperSU's ZIP file and extracted it, changed to that folder, then:
(note that my adb shell to my emulator image has # root by default)
Resulting in:
So, I'm really not sure what might be going on with your setup, but I don't think its SuperSU itself, but rather the emulator.
Note that to use supolicy --file, you only need supolicy and libsupol.so, you don't even need root.
Click to expand...
Click to collapse
Hmm, I really don't know what is wrong, I will try exactly what you have done later today, to see If can reproduce the output. If it doesn't work then we can pin it down to the emulator itself. What emulator image did you use?
I also realise that so emulator are rooted in the sense that web shell has root acess, just wasn't sure what dependices supolicy had at the time.
Matt07211 said:
Hmm, I really don't know what is wrong, I will try exactly what you have done later today, to see If can reproduce the output. If it doesn't work then we can pin it down to the emulator itself. What emulator image did you use?
I also realise that so emulator are rooted in the sense that web shell has root acess, just wasn't sure what dependices supolicy had at the time.
Click to expand...
Click to collapse
I created an API 22 Google Nexus x86_64 AVD in Android Studio
I should be able to try that in about 20-30 mins after I download it, I was using api level 19, Intel's emulator image.
I ran these commands on the Intel api 19 x86 emulator image.
Code:
adb push libsupol.so /system/lib/libsupol.so
adb shell chmod 0644 /system/lib/libsupol.so
adb push /system/xbin/supolicy
adb shell chmod 0755 /system/xbin/supolicy
adb push supolicy /data/local/tmp/supolicy
adb shell chmod 0755 /data/local/tmp/supolicy
adb push sepolicy /data/local/tmp/sepolicy
adb shell
cd /data/local/tmp
chmod 0755 supolicy
LD_LIBRARY_PATH=/data/local/tmp:$LD_LIBRARY_PATH ./supolicy --file sepolicy sepolicy_out
and it results in the error(shown in screenshot)
Code:
libsepol.policydb_read: policydb magic number 0x464c457f does not match expected magic number 0xf97cff8c or 0xf97cff8d
-Failure!
I then tried it on the Intel x86_64 api 22 emulator image (running the same commands as the first one, resulting in a succes, with the file being outputted as the sepolicy_out.
So as you have stated @Chainfire , it looks like a problem with the emulator itself, and most likely not the supolicy tool.
Chainfire said:
So, I think it has something to do with your emulator image (perhaps its too old ?)
I took SuperSU's ZIP file and extracted it, changed to that folder, then:
(note that my adb shell to my emulator image has # root by default)
Code:
adb push c:\download\sepolicy /data/local/tmp/sepolicy
adb push x86\. /data/local/tmp/.
adb shell
cd /data/local/tmp
chmod 0755 supolicy
LD_LIBRARY_PATH=/data/local/tmp:$LD_LIBRARY_PATH ./supolicy --file sepolicy sepolicy_out
exit
Resulting in:
Code:
supolicy v2.78 (ndk:x86) - Copyright (C) 2014-2016 - Chainfire
Patching policy [sepolicy] --> [sepolicy_out] ...
- Success
So, I'm really not sure what might be going on with your setup, but I don't think its SuperSU itself, but rather the emulator.
Note that to use supolicy --file, you only need supolicy and libsupol.so, you don't even need root.
Click to expand...
Click to collapse
@Chainfire, I'm trying to patch sepolicy for a Samsung device running Nougat, so that Supersu can be installed in system mode. Could you confirm if the --sdk=24 parameter is required?
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out --sdk=24"
Thanks, appreciate your time.
ashyx said:
@Chainfire, I'm trying to patch sepolicy for a Samsung device running Nougat, so that Supersu can be installed in system mode. Could you confirm if the --sdk=24 parameter is required?
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out --sdk=24"
Thanks, appreciate your time.
Click to expand...
Click to collapse
Yes it is.
System mode hasn't been tested at all on 7.0 though. I'm not sure anybody has been able to get it to work at this point.
If you do, let me know and with the steps
Chainfire said:
Yes it is.
System mode hasn't been tested at all on 7.0 though. I'm not sure anybody has been able to get it to work at this point.
If you do, let me know and with the steps
Click to expand...
Click to collapse
Hmm wasn't aware of the lack of support for system mode in nougat, any plans to implement?
It seems system mode root renders the device unbootable according to reports from my tester.
Question, if I modify the supersu script to mount su.img from /system am I likely to hit issues?
Seems a strange query I know.
Reason is we have a Samsung device that for some reason will not boot from a source built custom Nougat kernel. Not sure if this is related to AVB yet or something else.
However we can get a half assed TWRP to boot with the stock kernel.
Only problem is, no matter what, only /system can be mounted and accessed with write permission due to permission denied issues with the rest of partitions. Pretty sure this is an SELinux issue.
Meaning systemless root cannot be installed as normal. No access to /data or /cache.
I can patch the boot.img ramdisk manually for systemless, but for root to work I would need to push su.img to system and mount it from there.
Is it possible to still mount su.img from system if I modify the ramdisk init as required?
The other avenue is to flash su.img to /data or /cache via ODIN.
If it was flashed to /cache would supersu automatically pick up its location and copy it to /data or would a flag need to be set?
Just trying to keep my options open here.
ashyx said:
Hmm wasn't aware of the lack of support for system mode in nougat, any plans to implement?
It seems system mode root renders the device unbootable according to reports from my tester.
Click to expand...
Click to collapse
It is on my list of things to test/fix, but that list is long and full of terrors.
Question, if I modify the supersu script to mount su.img from /system am I likely to hit issues?
Is it possible to still mount su.img from system if I modify the ramdisk init as required?
Click to expand...
Click to collapse
I think that could work, yes.
The other avenue is to flash su.img to /data or /cache via ODIN.
If it was flashed to /cache would supersu automatically pick up its location and copy it to /data or would a flag need to be set?
Just trying to keep my options open here.
Click to expand...
Click to collapse
SuperSU should pick it up from /cache. Alternatively, try SuperSU's FRP mode, which stores a copy of the needed files in the boot-image and re-creates /data/su.img as needed.
Chainfire said:
It is on my list of things to test/fix, but that list is long and full of terrors.
I think that could work, yes.
SuperSU should pick it up from /cache. Alternatively, try SuperSU's FRP mode, which stores a copy of the needed files in the boot-image and re-creates /data/su.img as needed.
Click to expand...
Click to collapse
Thanks, great info as always. Finally managed to root the damn thing by adding a short script to the init which copies su.img to cache.
However FRP mode sounds like a more elegant solution if I can work out how to implement it in the Ramdisk.
Much appreciate your input.
ashyx said:
So, I think it has something to do with your emulator image (perhaps its too old ?)
...
Could you confirm if the --sdk=24 parameter is required?
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out --sdk=24"
Thanks, appreciate your time.
Click to expand...
Click to collapse
Yea believe it was segfaulting due to the Android version, I think I was using KitKat and it wasn't working, bumped up to lollipop and above and it worked fine
Oh, the SDK parameter, never heard of it, what does it do? Geuss I'll Google that then.
ashyx said:
Thanks, great info as always. Finally managed to root the damn thing by adding a short script to the init which copies su.img to cache.
However FRP mode sounds like a more elegant solution if I can work out how to implement it in the Ramdisk.
Much appreciate your input.
Click to expand...
Click to collapse
I did the same thing for my device, add a little script to move it to data. Had no other way to get it to a locked down device without TWRP. Hehe. Good job
Can you please tell me how to manually patch init by supersu ?
I've googled a lot, but haven't found a way to manually patch init by supersu.
My model is Honor v10, there isn't a custom recovery, so i have to make a boot.img with supersu inside to get root.
I recently got a repaired Moto X Pure Edition running Marshmallow. I unlocked the bootloader and used fastboot to start TWRP, then set up the systemless install of SuperSU 2.79. The installation seemed successful. I watched it patch the boot image and upon reboot, the SuperSU app was available. It seems happy when I run it.
However, if I run the terminal emulator and type "su", it stalls indefinitely. Nothing happens. The SuperSU "allow/deny" dialog does not appear and nothing shows up in the SuperSU logs. The same happens when I run su via "adb shell" on my PC. TitaniumBackup also stalls when it starts with "Detecting SU and Busybox".
I originally installed SuperSU 2.79, then found the SR3 update and installed that as well. Both had the same problem. The su binary is not completely broken, as some commands work.
Some commands that work:
Code:
[email protected]:/ $ su -v
2.79:SUPERSU
Code:
[email protected]clark:/ $ su -V
279
Code:
[email protected]:/ $ su --help
SuperSU v2.79 (ndk:arm64-v8a) - Copyright (C) 2012-2017 - Chainfire & CCMT
...
Any idea why SuperSU isn't working?
Okay, here's another data point. I switched the default permission from "Prompt" to "Grant", and I can get root. The problem has something to do with showing the dialog.
I figured it out. In a previous cleanup attempt, I failed to restore the link named /system/bin/app_process that points to /system/bin/app_process64. This fixed it:
From the TWRP terminal:
Code:
mount /system
cd /system/bin
ln -s app_process64 app_process