[Q] Rooting a Trekstor Surftab breeze 10.1 quad [SOLVED] - Android Q&A, Help & Troubleshooting

Hi, I've recently acquired a Trekstor Surftab breeze 10.1 quad and my first (admittedly inexperienced) attempts at rooting it have failed miserably.
The tablet is a 10.1 inch 8GB device with a Mediatek MT8127 running Android 4.4.2 (Kernel 3.4.67 [email protected] #1). I tried first with Towelroot (including the various advanced modes), which did nothing, not even the temporary root option. Kingo Root and iRoot (former vRoot) are able to connect to the tablet in debug mode, but after trying several scripts and rebooting the device a few times they ultimately failed.
I'd rather not change the recovery without a having a backup, but I tried MTK Tools to at least get some useful information. I couldn't get a scatter file because the button was greyed out (I don't think the program is fully compatible with the MT8127), but the partitioning info was slightly different from other MT8127-based devices (I checked the Cube U27GT MT8127 tablet). Getting a scatter file from an existing ROM (or just modifying a ROM to add the su binary) seems to be out of the question, because I couldn't find one on the Trekstor site and a quick Google search gave me nothing. I also tried to get temporary root but it failed with a suggestion to install CWM recovery.
Also, just in case I was being an idiot and the tablet came with the su binary already installed (other Trekstor devices do), I tried installing SuperSU directly, but I had no such luck.
If I find anything else I'll post it here, but for the time being I've run out of ideas. Any suggestions?
I've finally cracked it and been able to put together some notes. They are intended for the Surftab Quad 10.1, but they might be useful with some modifications for other devices based on a Mediatek SOC that can't be rooted using the usual tools (or if you don't trust the usual tools). I've tried to attach the programs I've used, but I've been having a lot of trouble because some files are too large. You can get everything from these Mega links instead:
ext4_utils_new_cygwin_fixed.tar.gz: https://mega.co.nz/#!YIkhFTRJ!uemCzV5fTlXoyK61Vr3Ib-sPXYlzmrffYG7YwUxXaU0
MT6577 USB VCOM drivers.rar: https://mega.co.nz/#!dcNx2QBC!eHyKtnwbVc2Gj5hCUQXQIlQsv9G3dGXWvPEvrB15mNw
MT8127_Android_scatter_surftab_quad_101.txt: https://mega.co.nz/#!Yd0nnRoL!s5ztQIwwZLa3i89zVU9vFJL0xZXg5LKqIDSkRAdj45k
MtkDroidTools v2.5.3.zip: https://mega.co.nz/#!0FVxjILC!0-FOlPfT_OIRETYj_MsJofmse7zBeRMsSumJLicj5sM
spflash_5.14.16.zip: https://mega.co.nz/#!hcE0HKBJ!mkcdVjXBOUs7W1GhTF_qssgO14GNGs7kSWaOE9FJx2o
UPDATE-SuperSU-v2.45.zip: https://mega.co.nz/#!BUMzRaaR!R7_kGU7UN3SchcaEDCxKW7Oehfoi0PDsD-OeX9gJh0M
1) Make (or in this case check) the scatter file with MTK Droid Tools.
a) Turn on the device.
b) Enable USB debug.
c) Connect it to the PC.
d) Open MTK Droid Tools.
e) Check that the device information is correct, view block map, compare with scatter file and modify if needed.​Alternatively, you can use the ADB terminal (it can be opened from MTK Droid Tools) and use the command “adb pull /proc/dumchar_info”. The resulting text file should contain the same information.
2) Install the VCOM drivers (I provide the Win7 version)
http://forum.xda-developers.com/showthread.php?t=2206421
http://forum.xda-developers.com/general/rooting-roms/guide-mediatek-spflashtool-failure-t2936933
The gist of it is, use USBDeview to remove any old VCOM drivers, install, reboot and plug in the switched off tablet. A new COM port-type device should flash for an instant in the device admin. Some guides recommend to change the preloader driver for DA, but in this case I found it not to be necessary. That said, the connection is a bit finicky and the USB cable that comes with the device and the port in the device itself seem to be pretty crappy, so in later steps it gave repeated COM errors unless I kept pressing on the micro USB connector or used a different cable altogether (the one belonging to my Kindle, to be precise). After a bit of trial and error, I also had a bit of trouble if the COM port assigned to the device was above port 9. That can be set in the device properties dialog, under the “Port configuration” tab and in “Advanced options”.
USBDeview might be necessary.
http://www.nirsoft.net/utils/usb_devices_view.html​
3) Extract the system image (and make a full backup, just in case) with SP Flash Tools.
a) With the device unplugged and turned off, start SP Flash Tool.
b) Load the scatter file.
c) Under the Readback tab, click on “Add” and double click on the new field. I recommend to back up the entire device first, so name the file “full_dump.img” or somesuch and save from 0x00000000 to 0x4db00000, which would be everything but the user data and BMTPOOL. Then we add a second dump, named “system.img” starting on 0x5d00000 and with size 0x40000000. Those values come from the scatter file. They shouldn’t change if the device is the same, but if they do modify them as fit.
c) With the device turned off, plug the micro-usb side of the cable first (it’s more convenient that way), click “read back” and insert the cable into the pc. As mentioned before, the process can fail for many reasons. Sometimes unplugging the device, pressing briefly the tablet’s reset button and trying again helps.​
4) Now prepare to continue working on Linux, a virtual machine like VirtualBox running Ubuntu should be enough. A bit over 2GB of free space will be needed.
a) Create a work directory, copy the system.img, ext4 utils and SuperSU files into it and open a terminal there.
b) If they aren't installed already, install compression and compilation tools (I might have been left out a few packages, I didn't have a clean setup to test it; if something isn't installed by default, finding the package shouldn't be hard). Assuming you are using Ubuntu:
Code:
sudo apt-get install unzip build-essential
c) Extract everything and compile the ext4 utils.
Code:
tar -xf ext4_utils_new_cygwin_fixed.tar.gz
unzip -d supersu UPDATE-SuperSU-v2.45.zip
cd ext4_utils_new; make; cd ..
d) Mount the original system image and copy everything it contains to a new directory.
Code:
mkdir system_old system_root
sudo mount -t ext4 -o loop system.img ./system_old
sudo cp -a system_old/* system_root
4) Install the SuperSU binaries and app.
The package I've included is intended to be installed automatically by the recovery menu, but we are going to do it manually by following the steps described in the setup script (supersu/META-INF/com/google/android/update-binary):
Code:
# API source target chmod chcon required
#
# 7-19 common/Superuser.apk /system/app/Superuser.apk 0644 u:object_r:system_file:s0 gui
# 20+ common/Superuser.apk /system/app/SuperSU/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 17+ common/install-recovery.sh /system/etc/install-recovery.sh 0755 *1 required
# 17+ /system/bin/install-recovery.sh (symlink to /system/etc/...) required
# *1: same as /system/bin/toolbox: u:object_r:system_file:s0 if API < 20, u:object_r:toolbox_exec:s0 if API >= 20
#
# 7+ ARCH/su /system/xbin/su *2 u:object_r:system_file:s0 required
# 7+ /system/bin/.ext/.su *2 u:object_r:system_file:s0 gui
# 17+ /system/xbin/daemonsu 0755 u:object_r:system_file:s0 required
# 17+ /system/xbin/sugote 0755 u:object_r:zygote_exec:s0 required
# *2: 06755 if API < 18, 0755 if API >= 18
#
# 19+ ARCH/supolicy /system/xbin/supolicy 0755 u:object_r:system_file:s0 required
# 19+ ARCH/libsupol.so /system/lib(64)/libsupol.so 0644 u:object_r:system_file:s0 required
#
# 17+ /system/bin/sh or mksh *3 /system/xbin/sugote-mksh 0755 u:object_r:system_file:s0 required
# *3: which one (or both) are available depends on API
#
# 21+ /system/bin/app_process32 *4 /system/bin/app_process32_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_process64 *4 /system/bin/app_process64_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_processXX *4 /system/bin/app_process_init 0755 u:object_r:system_file:s0 required
# 21+ /system/bin/app_process (symlink to /system/xbin/daemonsu) required
# 21+ *4 /system/bin/app_process32 (symlink to /system/xbin/daemonsu) required
# 21+ *4 /system/bin/app_process64 (symlink to /system/xbin/daemonsu) required
# *4: Only do this for the relevant bits. On a 64 bits system, leave the 32 bits files alone, or dynamic linker errors
# will prevent the system from fully working in subtle ways. The bits of the su binary must also match!
#
# 17+ common/99SuperSUDaemon *5 /system/etc/init.d/99SuperSUDaemon 0755 u:object_r:system_file:s0 optional
# *5: only place this file if /system/etc/init.d is present
#
# 17+ 'echo 1 >' or 'touch' *6 /system/etc/.installed_su_daemon 0644 u:object_r:system_file:s0 optional
# *6: the file just needs to exist or some recoveries will nag you. Even with it there, it may still happen.
#
# It may seem some files are installed multiple times needlessly, but
# it only seems that way. Installing files differently or symlinking
# instead of copying (unless specified) will lead to issues eventually.
#
# The following su binary versions are included in the full package. Each
# should be installed only if the system has the same or newer API level
# as listed. The script may fall back to a different binary on older API
# levels. supolicy are all ndk/pie/19+ for 32 bit, ndk/pie/20+ for 64 bit.
#
# binary ARCH/path build type API
#
# arm-v5te arm aosp static 7+
# x86 x86 aosp static 7+
#
# arm-v7a armv7 ndk pie 17+
# mips mips ndk pie 17+
#
# arm64-v8a arm64 ndk pie 20+
# mips64 mips64 ndk pie 20+
# x86_64 x64 ndk pie 20+
#
# Note that if SELinux is set to enforcing, the daemonsu binary expects
# to be run at startup (usually from install-recovery.sh, 99SuperSUDaemon,
# or app_process) from u:r:init:s0 or u:r:kernel:s0 contexts. Depending
# on the current policies, it can also deal with u:r:init_shell:s0 and
# u:r:toolbox:s0 contexts. Any other context will lead to issues eventually.
#
# After installation, run '/system/xbin/su --install', which may need to
# perform some additional installation steps. Ideally, at one point,
# a lot of this script will be moved there.
#
# The included chattr(.pie) binaries are used to remove ext2's immutable
# flag on some files. This flag is no longer set by SuperSU's OTA
# survival since API level 18, so there is no need for the 64 bit versions.
# Note that chattr does not need to be installed to the system, it's just
# used by this script, and not supported by the busybox used in older
# recoveries.
#
# Non-static binaries are supported to be PIE (Position Independent
# Executable) from API level 16, and required from API level 20 (which will
# refuse to execute non-static non-PIE).
#
# The script performs serveral actions in various ways, sometimes
# multiple times, due to different recoveries and firmwares behaving
# differently, and it thus being required for the correct result.
What the script is supposed to do depends on the API version, which can be identified by doing:
Code:
cat system_root/build.prop | grep "ro.build.version.sdk="
We should have API version 19, but at one point the instructions are misleading. When adjusting the security context of install-recovery.sh it states that it should match that of toolbox, which is correct, but next gives values for different API versions which do not match our case. We shouldn't trust them and use
Code:
ls -Z system_root/bin/toolbox
to obtain the right value, in our case ubject_r:toolbox_exec:s0 (as in API version higher than 20).
Next I give all the commands, so assuming the directory names are the same I used they can just be copied and pasted into the terminal:
Code:
sudo cp supersu/common/Superuser.apk system_root/app/
sudo chmod 0664 system_root/app/Superuser.apk
sudo chcon u:object_r:system_file:s0 system_root/app/SuperSU/SuperSU.apk
sudo cp supersu/common/install-recovery.sh system_root/etc/
sudo chmod 0755 system_root/etc/install-recovery.sh
#we have to copy the chcon of system_root/bin/toolbox: ls -Z system_root/bin/toolbox, the original script is misleading or our android setup isn't standard.
sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
sudo ln -s /system/etc/install-recovery.sh system_root/bin/install-recovery.sh
sudo cp supersu/armv7/su system_root/xbin/
sudo mkdir system_root/bin/.ext
sudo cp supersu/armv7/su system_root/bin/.ext/.su
sudo chmod 0755 system_root/xbin/su system_root/bin/.ext/.su
sudo chcon u:object_r:system_file:s0 system_root/xbin/su system_root/bin/.ext/.su
sudo cp supersu/armv7/su system_root/xbin/daemonsu
sudo cp supersu/armv7/su system_root/xbin/sugote
sudo chmod 0755 system_root/xbin/daemonsu system_root/xbin/sugote
sudo chcon u:object_r:system_file:s0 system_root/xbin/daemonsu
sudo chcon u:object_r:zygote_exec:s0 system_root/xbin/sugote
sudo cp supersu/armv7/supolicy system_root/xbin/
sudo cp supersu/armv7/libsupol.so system_root/lib/
sudo chmod 755 system_root/xbin/supolicy
sudo chmod 0755 system_root/xbin/supolicy
sudo chmod 0644 system_root/lib/libsupol.so
sudo chcon u:object_r:system_file:s0 system_root/xbin/supolicy
sudo chcon u:object_r:system_file:s0 system_root/lib/libsupol.so
sudo cp system_root/bin/mksh system_root/xbin/sugote-mksh
sudo chmod 0755 system_root/xbin/sugote-mksh
sudo chcon u:object_r:system_file:s0 system_root/xbin/sugote-mksh
6) Generate a new image file with make_ext4fs.
Code:
./ext4_utils_new/make_ext4fs -a system -l 1G system_root.img system_root/
We can now mount it and verify that the files are in place and with the right permissions.
Code:
mkdir system_test
sudo mount -t ext4 -o loop system_root.img ./system_test
ls -la system_test/app/SuperSU.apk
ls -Z system_test/app/SuperSU.apk
ls -la system_test/xbin/su
ls -Z system_test/xbin/su
And finally unmount everything
Code:
sudo umount system_root
sudo umount system_test
7) Return to Windows and flash our rooted system image.
a) Open the flash tool, checking that we have loaded the right scatter file.
b) Select “download only” in the drop-down menu, make sure only “ANDROID” is checked in the list and, double-clicking that entry, pick the system_rooted.img file we have just created.
c) Just as when we extracted the image, we press “Download” and plug in the USB cable with the device turned off. ​Note: If you have been using a virtual machine, at some point mounted the rooted image to check that all the files were in place and forgot to unmount it, the file will be locked and the flash tool can spit out an error message. It took me a few tries to notice and shut down the VM completely. Don’t be me.
8) After it has finished flashing, unplug the device and boot it again. The first time it boots it should show a boot message saying that it’s updating one app, and once it’s finished we should have a working rooted tablet.

Same here with the trekstor surftab breeze 7.0 quad (ST70408-2).
I have tried everything with no results...

did you try rootgenius? (shuame.com/en/root/)

Y es. I have tried with no results.
Sent from my XT1032 using xda premium

I did it the hard way, eventually. I dumped the original rom, mounted it on linux, copied all the SU binaries manually in the right places (following the instructions in the installation script), and flashed it back.
I'm not sure if I can get in trouble for uploading the whole rooted ROM, but as soon as I have some free time I'd like to at least post more detailed instructions, the programs I used and the scatter file for my 10.1 quad in case someone finds it useful.

I would really appreciate if you could find the time to add a description.
I have a Surftab Breeze 7.0 quad and I am struggeling with backing it up and rooting it.
Looking forward to reading your notes.

sdfsdfgdhshxzv said:
I did it the hard way, eventually. I dumped the original rom, mounted it on linux, copied all the SU binaries manually in the right places (following the instructions in the installation script), and flashed it back.
I'm not sure if I can get in trouble for uploading the whole rooted ROM, but as soon as I have some free time I'd like to at least post more detailed instructions, the programs I used and the scatter file for my 10.1 quad in case someone finds it useful.
Click to expand...
Click to collapse
can u attach your scatterfile plz?

mr9to5 said:
can u attach your scatterfile plz?
Click to expand...
Click to collapse
Sure. This is for my MT8127-based Trekstor Surftab Quad 10.1.
Sorry about the rest of my notes, I've just changed jobs and I'm having a few horribly busy weeks so I've had no time to make them presentable. But once you have the utilities to mount the image on linux, it's just a matter of extracting the supersu archive and looking into the setup script to see where every file goes, where to create links and which permissions to set for the right Android version.

I've finally added my step by step notes to the first post. I hope someone finds them useful.

sdfsdfgdhshxzv said:
I've finally added my step by step notes to the first post. I hope someone finds them useful.
Click to expand...
Click to collapse
very useful, but i have a big problem.
Code:
$ sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
chcon: ungültiger Kontext: u:object_r:toolbox_exec:s0: Datei oder Verzeichnis nicht gefunden
can u help?

mr9to5 said:
very useful, but i have a big problem.
Code:
$ sudo chcon u:object_r:toolbox_exec:s0 system_root/etc/install-recovery.sh
chcon: ungültiger Kontext: u:object_r:toolbox_exec:s0: Datei oder Verzeichnis nicht gefunden
can u help?
Click to expand...
Click to collapse
Hum... not sure what happened there. Can you please try this? (assuming you have used the same directory names I did, change them if you haven't)
Code:
ls -Z system_root/etc/install-recovery.sh
ls -Z system_old/bin/toolbox

sdfsdfgdhshxzv said:
Hum... not sure what happened there. Can you please try this? (assuming you have used the same directory names I did, change them if you haven't)
Code:
ls -Z system_root/etc/install-recovery.sh
ls -Z system_old/bin/toolbox
Click to expand...
Click to collapse
it works, but this errormessages are from selinux, the copied files have no content so we can´t change this.

Sucefull startet CWM recovery
not perfect but runs, incl adb root shell in recovery mode.

la solución al root de esta tablet esta aquí w w w . m g y u n . c o m /
100% efectiva.
---------- Post added at 12:47 PM ---------- Previous post was at 12:11 PM ----------
¿algun propietario de la surftab brisa 10.1 quad, me podría enviar las apk de bluetooth ?
es que manipulando un explorador root he borrado por equivocación estos archivos y no me funciona el bluetooth de la tablet.
gracias.

Related

[HOW TO] Install/Run Android SDK 64 Bit Native on Device

I learned about this here... http://fieldeffect.info/w/NativeCompileSDK
You can install an i386/x86_64 chroot within your existing Debian chroot using qemu-user-static to run the Android SDK on your Android phone/tablet/phablet.
1.
Get yourself a debian chroot, I recommend at least 2gb. I use DebianKit from market.
2.
You will need a X11 desktop environment and a VNC client on your device. I use androidVNC from market.
Here is my working example...
Start your Debian chroot/environment and do...
apt-get install openbox openbox-themes obmenu obconf menu menu-xdg xdg-utils xfonts-base xfonts-terminus* nautilus terminator lxappearance gmrun leafpad man-db hicolor-icon-theme tightvncserver tint2
That gives you a window manager, fonts, filebrowser, terminal emulator, text editor, theme manager, taskbar, and a VNC server.
Now lets get some GTK engines and libraries....
apt-get install gtk2-engines-auroa gtk2-engines-murrine gtk2-engines-oxygen gtk2-engines-pixbuf libgtk2.0-bin gtk3-engines-oxygen gtk3-engines-unico libgtk-3-bin
Now 7zip to handle zips and archives comfortably(put non-free in your apt sources.list)...
apt-get install p7zip p7zip-full p7zip-rar zip unzip
##The Android SDK manager, qemu, and multistrap##
apt-get install ant file openjdk-6-jre openjdk-6-jdk qemu-user-static libswt-gtk-3-java libswt-cairo-gtk-3-jni
3.
Now we can build a small x86_64 rootfs using multistrap
multistrap can use a config, have mine...
http://db.tt/hS5j3wg
Copy multistrap.conf straight into your working(pwd) directory....
cp /sdcard/Download/multistrap.conf .
Do this to avoid multistrap complaining later...
cat multistrap.conf >mstrap
mkdir /data/mnt
Determine size of rootfs for loop image..
du -hs /data/mnt/
Now make an image for x86_64 chroot
dd if=/dev/zero of=/sdcard/64bit.img bs=$(( 0x100000 )) count=YOUR IMAGE SIZE
That byte size makes your image slightly larger than the count value in Mb, for example count=78 will write 82Mb image.
mkfs.ext2 /sdcard/64bit.img
tune2fs -c0 /sdcard/64bit.img
mkdir /data/tmp
busybox mount -o loop /sdcard/64bit.img /data/tmp/
cp -r /data/mnt/* /data/tmp/
umount /data/tmp
rm -r /data/tmp/
rm -r /data/mnt/
mkdir /data/mnt
busybox mount -o loop /sdcard/64bit.img /data/mnt/
5.
Now the environment is set up and mounted, at this point install the SDK
Aim your browser to http://developer.android.com/sdk/index.html
Select "Linux" from "SDK Tools Only", thats the last thing at the bottom of the list.
cp /sdcard/Download/android-sdk_r21.0.1-linux.tgz .
7z x android-sdk_r21.0.1-linux.tgz russosv
7z x android-sdk_r21.0.1-linux.tar
Now we need a couple goodies from http://fieldeffect.info/w/NativeCompileAPK ##--Thanks to russosv from FeildEffect
These are edited from original....
#!/bin/bash
QEMU=/usr/bin/qemu-x86_64-static
64CHROOT=/data/mnt/
case "$1" in
mklinks)
if [ ! -e "./64BIT" ]; then
mkdir ./64BIT
fi
for i in $(file ./* | grep "ELF 32" | awk '{print $1}' | sed s/://g | sed s/[./]//g); do
echo "Moving $i..."
mv $i ./64BIT
ln -s ~/bin/run-64-link $i
done-
;;
*)
$QEMU $64CHROOT/lib64/ld-linux-x86_64.so.2 --library-path $64CHROOT/lib:$64CHROOT/usr/lib:$64CHROOT/usr/share/perl/5.12.4/unicore/lib:$64CHROOT/var/lib:$64CHROOT/lib/x86_64-linux-gnu:$64CHROOT/usr/lib/x86_64-linux-gnu [email protected]
;;
esac
Copy that to run-64, then...
chmod 755 run64
cp run-64 /usr/bin/
One more...
echo $(dirname $0)/64BIT/$(basename $0) [email protected]
/usr/bin/run-i386 $(dirname $0)/64BIT/$(basename $0) [email protected]
Make that run-64-link
chmod 755 run-64-link
cp run-64-link /usr/bin/
5b.
Now launch VNC server
tightvncpasswd
tightvncserver
killall Xtightvnc
cat >.vnc/xstartup<<EOF
tint2 &
terminator &
openbox-session
EOF
tightvncserver
export DISPLAY=:1
6.
Now launch the VNC client I mentioned earlier, should connect with 127.0.0.1:5901 and your password you set.
Go back to terminal or use the one launched on X11 to do...
sh android-sdk-linux/tools/android
Install at least one api.
If all went well you can now go around "debugging" yours and your friends Android devices over wifi now.
For an example, and to see it work do....
svc wifi disable(or enable) ##this turns off/on wifi
setprop service.adb.tcp.port 5555(or -1) ##this turns on/off adb over network
stop adbd
start adbd
adb connect 127.0.0.1(yours) or any other adbd addy listening on your network,
Have fun
Never did a "how to" before, go easy and I'll make corrections and answer things. Thanks for reading. Leave feedback.
Potential necro post but I believe the information is still currently valid and not readily available on searches. I've looked variations of this up for years with no luck until I hit the right search terms.
bump, and thanks.
can't believe there's no comments.
I know it's a slower than real-64-bit-pc method but not all of us have access to new hardware... or pc's. Maybe a novelty, still cool and useful if you've got the time to let the slower hardware compile.
you have preserved the scripts, original link is dead.
here is the Internet Wayback Machine cache of the original circa 2012 for reference.
http://web.archive.org/web/20120502044700/http://fieldeffect.info/w/NativeCompileAPK
appreciate you sharing.

[NEW] One CLICK root GS701B based ATM7013 cpu

HI
i present you one clik root just changed su binary with MIPS platform one
1) be sure adb drivers are correctly installed and they are included in the file and debuggging is activate on yr tablet
2) with
adb shell
$ su
# mount -o remount,rw /system
# cd /system/xbin
# mv su oldsu (rename su to oldsu or backup the original su with new name )
3) install SRS on click root from http://www.srsroot.com/
4) download modified SU for MIPS platform form here http://www.4shared.com/rar/cPXnpT6E/srsroot.html and extract it anywhere on your computer
5) launch SRS-One-Click-Root
6) click on smart Root
and let it working
it must be display root will be availabler after reboot
verify your tablet if its rooted on site http://www.srsroot.com/supported
enjoy
rafik23 said:
HI
i present you one clik root just changed su binary with MIPS platform one
1) be sure adb drivers are correctly installed and they are included in the file and debuggging is activate on yr tablet
2) with
adb shell
$ su
# mount -o remount,rw /system
# cd /system/xbin
# mv su oldsu (rename su to oldsu or backup the original su with new name )
3) install SRS on click root from http://www.srsroot.com/
4) download modified SU for MIPS platform form here http://www.4shared.com/rar/cPXnpT6E/srsroot.html and extract it anywhere on your computer
5) launch SRS-One-Click-Root
6) click on smart Root
and let it working
it must be display root will be availabler after reboot
verify your tablet if its rooted on site http://www.srsroot.com/supported
enjoy
Click to expand...
Click to collapse
when i type su it is asking for a password???? why is this??
EDIT found password "actions123"
Hello,
I have this :
[email protected]:/ $ su
su
/system/bin/sh: /system/bin/su: not executable: magic 7F45
I don't understand why I can't root it ?
I don't have password and I can't do this :
mount -o remount,rw /system
mv /system/xbin/su /system/xbin/su.org
cp /sdcard/busybox /system/xbin/busybox
cp /sdcard/su /system/bin/su
chmod 06755 /system/bin/su
chmod 04755 /system/xbin/busybox
/system/xbin/busybox --install -s /system/xbin
ln -s /system/bin/su /system/xbin/su
More information :
1|[email protected]:/ # cat /proc/cpuinfo
cat /proc/cpuinfo
system type : actions-atv5201
processor : 0
cpu model : MIPS 74Kc V5.0 FPU V0.0
BogoMIPS : 389.59
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0000, 0x07
f8, 0x07f3]
ASEs implemented : mips16 dsp
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
Thanks per advance
Bye
Hello.
I think something still wrong here or im doing something wrong.
I did everything in the tuturial, at the end it says: "Root Complete", i get the "superuser" installed but i still dont have access to the root and the superuser still dont work properly.
What could be happaning?
If anyone can help me i would apprecciate.
Cumpa

[HOWTO] Run Gentoo Linux on the X+ (chroot)

Hi,
Can't really find a tutorial for our phone, so I'll be, well, making a tutorial
Some notes:
- Compiling is really slow, VERY. Probably RasPi speed.
- Putting the chroot in a specific location helps, due to our phone having weird mountpoints (try typing `mount` and see what happens)
- You can ADB shell into the phone, type "stop" so Zygote is stopped (less RAM usage, less CPU usage, basically pure Linux is running)
- ^ Remember to type "start" after finished playing with the chroot, or you get a frozen phone until forced reboot!
You may be able to adapt this guide to other distros too (although unlikely)
REQUIREMENTS
- Enough juice for playing games for a long time
- A WORKING busybox with "tar xvjpf" available
- You are rooted
1. First of all, su and mount root read/write.
Code:
su; mount -o remount,rw /
2. cd into /data/local
Code:
cd /data/local
3. mkdir linux (or other names if you prefer)
Code:
mkdir linux
4. cd into it
Code:
cd linux
5. Download a stage3 tarball USE ARMv7l, our phone isn't hard-floated and put it in current directory.
- If you use an external browser, make sure the permissions isn't set to r--------, chmod 755 to be sure
- If you use wget, you probably don't have to worry about permissions
6. Extract it. Replace blahblahblah with your file name
Code:
tar xvjpf blahblahblah.tar.bz2
7. Make a chroot script which contains all the necessary bind mounts and commands. Make sure it is in the same dir as your chroot!
Code:
#!/system/bin/sh
# Enable network forwarding to the chroot
sysctl -w net.ipv4.ip_forward=1
# Mount proc to "current directory"/proc
mount -t proc proc proc/
# Mount sys, bind
mount -o bind /sys sys/
# Mount dev, bind
mount -o bind /dev dev/
# Symlink proc/self/fd to dev/fd, or portage will fail
ln -s proc/self/fd dev/
# Write resolvconf
echo "8.8.8.8" > etc/resolv.conf
# Make sure the permissions are correct
chmod 755 etc/resolv.conf
# Chroot using /bin/bash as shell
chroot . /bin/bash
Then chmod 755 the script
Code:
chmod 755 chroot.sh
8. All Gentoo users should know this...
Code:
source /etc/profile
9. Edit /etc/portage/make.conf
Code:
nano /etc/portage/make.conf
10. Add these lines to it
Code:
# This will disable userfetch, making name resolution work.
FEATURES="-userfetch"
11. Adjust USE flags and other configs as necessary... save it
12. Enjoy Gentoo on your phone! :laugh::laugh:
13. Just Ctrl+D to exit chroot

Installing SuperSU root on Mi 5c

Here's a guide + script for installing SuperSU root on the Mi 5c.
I haven't yet managed to build a TWRP recovery image for it (I haven't really tried) - so this can be used to get root in the mean-time. (I also saw a Chinese TWRP ROM on the MIUI forums, but I haven't tried it myself)
Obviously modifying the phone system is risky, you may void the warranty, break it etc. I take no responsibility for that, and you use the instructions below at your own risk.
The script, and a few other tools I'm using for the Mi 5c can be found in my git repo: github.com/usedbytes/meri_tools
To use the script, you'll need a linux (or Mac, probably) computer with gcc and git installed, as well as a new-ish version of adb and fastboot. I'm running it on Arch Linux fine.
First get the phone into developer mode (tap on the MIUI version in About Phone 7 times), and enable adb debugging, and approve your computer to access debugging.
Then you need to download and extract the SuperSU "Installable Recovery" zip, and the Xiaomi stock ROM, which we will use for the install files.
Then, run the script below (meri_root.sh in the git repo).
The script installs all the bits needed, then reboots the phone with a rooted boot image. To make the root persistent, you need to flash the boot.supersu.img to the boot partition with fastboot (it just boots it by default).
Code:
#!/bin/bash
#
# Script to root the Xiaomi Mi 5c, by manually installing SuperSU
#
# Copyright 2017 Brian Starkey
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# -- Disclaimer
#
# Obviously modifying your phone can be dangerous, void the warranty etc. etc.
# Use this script and the instructions within it at your own risk.
#
# -- Description
#
# The SuperSU installer seems to assume you already have root, and is intended
# to be run from a custom recovery (like TWRP). We don't have that, so we'll do
# some funny dances to do a systemless root without having root to begin with.
#
# The crux of the matter is using SuperSU's tools to patch the ramdisk and
# sepolciy (in /data/local/tmp, without root), then building a ramdisk with
# those components
#
# -- Usage
#
# Plug in the phone, make sure you have (persistent) adb debugging permissions
# and run this script like so:
# meri_root.sh SUPERSU_DIR ROM_DIR
# Where SUPERSU_DIR is a directory where you have downloaded and extracted the
# SuperSU "Recovery Flashable" zip file: http://www.supersu.com/download
# and ROM_DIR is a directory where you have downloaded and extracted the ROM
# from Xiaomi's download page: http://en.miui.com/download-322.html
#
# The script will make and boot a boot.img which enacts a systemless root.
# To make it persisent, you must flash it instead:
# fastboot flash boot.supersu.img
#
# By default, SuperSU removes dm-verity from /system and encryption from /data
# To prevent this, set PRESERVE_VERITY=1 before running the script:
# PRESERVE_VERITY=1 ./meri_root.sh ...
if [ $# -ne 2 ];
then
cat >&2 <<EOM
Usage: $(basename $0) SUPERSU_DIR ROM_DIR
Extract SuperSU zip file into SUPERSU_DIR, and the Xiaomi ROM into ROM_DIR,
then run this script.
EOM
exit 1
fi
SUPERSU_DIR=$1
echo ${SUPERSU_DIR}/arm64/su
if [ ! -f ${SUPERSU_DIR}/arm64/su ]
then
echo "Invalid SUPERSU_DIR" >&2
exit 1
fi
ROM_DIR=$2
if [ ! -f ${ROM_DIR}/boot.img ]
then
echo "Invalid ROM_DIR" >&2
exit 1
fi
# 1. Get mkbootimg and build it
git clone --depth 1 https://github.com/osm0sis/mkbootimg.git || exit 1
cd mkbootimg
make || ( cd .. && exit 1 )
cd ..
# 2. Copy the SuperSU binaries to the device
echo "Waiting for device..."
adb wait-for-usb-device
adb push ${SUPERSU_DIR}/arm64/*su* /data/local/tmp/ || exit 1
adb shell chmod +x /data/local/tmp/su*
# 3. Create the SuperSU systemless root image
# Ideally we'd set up security contexts too, but then you need to be running
# on an SELinux-enabled kernel in permissive mode.
# Instead, we will fix it on first boot.
dd if=/dev/zero bs=1M count=96 of=su.img
mkfs.ext4 su.img
mkdir mnt
sudo mount su.img mnt
sudo mkdir mnt/{bin,xbin,lib,etc,su.d}
sudo chmod 0751 mnt/bin
sudo chmod 0755 mnt/{xbin,lib,etc}
sudo chmod 0700 mnt/su.d
sudo cp ${SUPERSU_DIR}/arm64/{su,sukernel} mnt/bin/
sudo cp ${SUPERSU_DIR}/arm64/su mnt/bin/daemonsu
sudo cp ${SUPERSU_DIR}/arm64/supolicy mnt/bin/supolicy_wrapped
sudo ln -s /su/bin/su mnt/bin/supolicy
sudo chown root:root mnt/bin/{su,daemonsu,sukernel,supolicy_wrapped}
sudo chmod 0755 mnt/bin/{su,daemonsu,sukernel,supolicy_wrapped}
sudo cp ${SUPERSU_DIR}/arm64/libsupol.so mnt/lib/libsupol.so
sudo chown root:root mnt/lib/libsupol.so
sudo chmod 0644 mnt/lib/libsupol.so
# Run a script at first-boot to fix up the SELinux contexts on the image
# It will remove itself after running
sudo bash -c "cat > mnt/su.d/firstboot.rc" <<EOF
#/system/bin/sh
chcon -hR u:object_r:system_data_file:s0 /su /data/local/tmp/su.img
rm /su/su.d/firstboot.rc
sync
EOF
sudo chmod 0750 mnt/su.d/firstboot.rc
sync
sudo umount mnt
# 4. Copy the systemless root image to the device
adb push su.img /data/local/tmp/su.img
# 5. Extract boot.img
mkdir bootimg
mkbootimg/unpackbootimg -o bootimg -i ${ROM_DIR}/boot.img
# 6. Unzip the ramdisk
cat bootimg/boot.img-ramdisk.gz | gunzip > ramdisk
# 7. Copy the ramdisk to the device, for patching
adb push ramdisk /data/local/tmp
# 8. Patch sepolicy and the ramdisk, using the SuperSU tools we copied over
# earlier
adb shell "
cd /data/local/tmp
LD_LIBRARY_PATH=. ./supolicy --file /sepolicy ./sepolicy.patched
LD_LIBRARY_PATH=. ./sukernel --patch ./ramdisk ramdisk.patched
"
# 9. Pull back the patched files
adb pull /data/local/tmp/sepolicy.patched /data/local/tmp/ramdisk.patched .
# 10. Extract the patched ramdisk, and install the patched sepolicy into it
mkdir ramdir
cat ramdisk.patched | sudo cpio --no-absolute-filenames -D ramdir -i
sudo cp sepolicy.patched ramdir/sepolicy
sudo chown root:root ramdir/sepolicy
sudo chmod 0644 ramdir/sepolicy
# 11. Install the SuperSU init scripts
sudo mkdir ramdir/su
sudo chmod 755 ramdir/su
sudo cp ${SUPERSU_DIR}/common/launch_daemonsu.sh ramdir/sbin
sudo chmod 744 ramdir/sbin/launch_daemonsu.sh
sudo chown root:root ramdir/sbin/launch_daemonsu.sh
sudo cp ${SUPERSU_DIR}/common/init.supersu.rc ramdir
sudo chmod 750 ramdir/init.supersu.rc
sudo chown root:root ramdir/init.supersu.rc
# 12. Patch the initscript for our img location and set the su.img context
sudo sed -i 's;/data/su.img;/data/local/tmp/su.img;' ramdir/init.supersu.rc
sudo sed -i '\;on property:sukernel.mount=1;a\ \ \ \ restorecon /data/local/tmp/su.img' ramdir/init.supersu.rc
sudo bash -c "echo /data/local/tmp/su.img u:object_r:system_data_file:s0 >> ramdir/file_contexts"
# Optional: Preserve dm-verity on /system, encryption on /data
if [ ! -z "$PRESERVE_VERITY" ] && [ $PRESERVE_VERITY -ne 0 ]
then
echo "Preserving dm-verity"
mkdir ramdir-stock
cat ramdisk | sudo cpio --no-absolute-filenames -D ramdir-stock -i
sudo cp ramdir-stock/{fstab.song,verity_key} ramdir/
sudo rm -rf ramdir-stock
fi
# 13. Repack the ramdisk
cd ramdir
sudo find . ! -path . | sudo cpio -H newc -o | gzip > ../ramdisk.gz
cd ..
# 14. Repack the boot image
mkbootimg/mkbootimg \
--kernel bootimg/boot.img-zImage \
--ramdisk ramdisk.gz \
--cmdline "console=ttyS0,115200 earlyprintk=uart8250-32bit,0xF900B000 androidboot.hardware=song no_console_suspend debug user_debug=31 loglevel=8" \
--base 0x0 \
--pagesize 4096 \
--kernel_offset 0x0a080000 \
--ramdisk_offset 0x0c400000 \
--dt bootimg/boot.img-dtb \
--tags_offset 0xc200000 \
--os_version 0.0.0 \
--os_patch_level 0 \
--second_offset 0x00f00000 \
--hash sha256 \
--id \
-o boot.supersu.img
# 15. Boot it! (flash it if you want to make it persistent)
adb reboot-bootloader
fastboot boot boot.supersu.img
echo "Waiting for device..."
adb wait-for-usb-device
Hi ,
Can you give me some advice on how to run this on Windows? I can get a adb shell but thats as far as I can get. I don't know how I am supposed to run the script.
Thanks
Stewart
Hello,
I am trying to root my mi 5c with your script, but I can't find sepolicy file on my phone, so for example this line can't be executed:
Code:
LD_LIBRARY_PATH=. ./supolicy --file /sepolicy ./sepolicy.patched
Do you know where I could find this file? I am using xiaomi.eu_multi_MI5c_7.4.6_v8-7.1 rom.
Hello,
I've had exactly the same issue on a multirom and on xiaomi.eu_multi_MI5c_7.4.20(although i'm not sure if installed rom has something to do with it)
blagon said:
...I am trying to root my mi 5c with your script, but I can't find sepolicy file on my phone...
Click to expand...
Click to collapse

Help including SuperSU and su binaries in stock ROM.

I would like some help in modifying my stock rom to include the SuperSU apk and all five su binaries (su, daemonsu, sukernel, supolicy and suinit).
I am aware that there are multiple tutorials out there for this kind of thing but what I'm trying to do requires the system be repacked into a sparse image to flash through fastboot as the phone has no TWRP build available.
Thank You.
Bythos73 said:
I would like some help in modifying my stock rom to include the SuperSU apk and all five su binaries (su, daemonsu, sukernel, supolicy and suinit).
I am aware that there are multiple tutorials out there for this kind of thing but what I'm trying to do requires the system be repacked into a sparse image to flash through fastboot as the phone has no TWRP build available.
Thank You.
Click to expand...
Click to collapse
Hello, you can unzip the flashable SuperSu zip and take a look at the update-binary script, this will shed some light on how the installation works, for example this is an excerpt taken from version 2.82:
Code:
#!/sbin/sh
#
# SuperSU installer ZIP
# Copyright (c) 2012-2017 - Chainfire, CCMT
#
# ----- GENERIC INFO ------
#
# The following su binary versions are included in the full package. Each
# should be installed only if the system has the same or newer API level
# as listed. The script may fall back to a different binary on older API
# levels. supolicy are all ndk/pie/19+ for 32 bit, ndk/pie/20+ for 64 bit.
#
# binary ARCH/path build type API
#
# arm-v5te arm ndk non-pie 7+
# x86 x86 ndk non-pie 7+
#
# x86 x86 ndk pie 17+ (su.pie, naming exception)
# arm-v7a armv7 ndk pie 17+
# mips mips ndk pie 17+
#
# arm64-v8a arm64 ndk pie 20+
# mips64 mips64 ndk pie 20+
# x86_64 x64 ndk pie 20+
#
# Non-static binaries are supported to be PIE (Position Independent
# Executable) from API level 16, and required from API level 20 (which will
# refuse to execute non-static non-PIE).
#
# The script performs several actions in various ways, sometimes
# multiple times, due to different recoveries and firmwares behaving
# differently, and it thus being required for the correct result.
#
# Overridable variables (shell):
# BIN - Location of architecture specific files (native folder)
# COM - Location of common files (APK folder)
# LESSLOGGING - Reduce ui_print logging (true/false)
# NOOVERRIDE - Do not read variables from /system/.supersu or
# /data/.supersu
#
# Overridable variables (shell, /system/.supersu, /cache/.supersu,
# /data/.supersu):
# SYSTEMLESS - Do a system-less install? (true/false, 6.0+ only)
# PATCHBOOTIMAGE - Automatically patch boot image? (true/false,
# SYSTEMLESS only)
# BOOTIMAGE - Boot image location (PATCHBOOTIMAGE only)
# STOCKBOOTIMAGE - Stock boot image location (PATCHBOOTIMAGE only)
# BINDSYSTEMXBIN - Poor man's overlay on /system/xbin (true/false,
# SYSTEMLESS only)
# PERMISSIVE - Set sepolicy to fake-permissive (true/false, PATCHBOOTIMAGE
# only)
# KEEPVERITY - Do not remove dm-verity (true/false, PATCHBOOTIMAGE only)
# KEEPFORCEENCRYPT - Do not replace forceencrypt with encryptable (true/
# false, PATCHBOOTIMAGE only)
# REMOVEENCRYPTABLE - Remove the encryptable flag, needed on newer
# Samsung devices to disable forced encryption
# (true/false, PATCHBOOTIMAGE only)
# FRP - Place files in boot image that allow root to survive a factory
# reset (true/false, PATCHBOOTIMAGE only). Reverts to su binaries
# from the time the ZIP was originall flashed, updates are lost.
# Shell overrides all, /data/.supersu overrides /cache/.supersu overrides
# /system/.supersu
#
# Note that if SELinux is set to enforcing, the daemonsu binary expects
# to be run at startup (usually from install-recovery.sh, 99SuperSUDaemon,
# app_process, or init.supersu.rc) from u:r:supersu:s0 (7.0+), u:r:init:s0 or
# u:r:kernel:s0 contexts. Depending on the current policies, it can also
# deal with u:r:init_shell:s0 and u:r:toolbox:s0 contexts. Any other context
# will lead to issues eventually.
#
# ----- "SYSTEM" INSTALL -----
#
# "System" install puts all the files needed in /system and does not need
# any boot image modifications. Default install method pre-Android-6.0
# (excluding Samsung-5.1).
#
# Even on Android-6.0+, the script attempts to detect if the current
# firmware is compatible with a system-only installation (see the
# "detect_systemless_required" function), and will prefer that
# (unless the SYSTEMLESS variable is set) if so. This will catch the
# case of several custom ROMs that users like to use custom boot images
# with - SuperSU will not need to patch these. It can also catch some
# locked bootloader cases that do allow security policy updates.
#
# To install SuperSU properly, aside from cleaning old versions and
# other superuser-type apps from the system, the following files need to
# be installed:
#
# API source target chmod chcon required
#
# 7-19 common/Superuser.apk /system/app/Superuser.apk 0644 u:object_r:system_file:s0 gui
# 20+ common/Superuser.apk /system/app/SuperSU/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 17+ common/install-recovery.sh /system/etc/install-recovery.sh 0755 *1 required
# 17+ /system/bin/install-recovery.sh (symlink to /system/etc/...) required
# *1: same as /system/bin/toolbox: u:object_r:system_file:s0 if API < 20, u:object_r:toolbox_exec:s0 if API >= 20
#
# 7+ ARCH/su *2 /system/xbin/su *3 u:object_r:system_file:s0 required
# 7+ /system/bin/.ext/.su *3 u:object_r:system_file:s0 gui
# 17+ /system/xbin/daemonsu 0755 u:object_r:system_file:s0 required
# *2: su.pie for 17+ x86(_32) only
# *3: 06755 if API < 18, 0755 if API >= 18
#
# 19+ ARCH/supolicy /system/xbin/supolicy 0755 u:object_r:system_file:s0 required
# 19+ ARCH/libsupol.so /system/lib(64)/libsupol.so 0644 u:object_r:system_file:s0 required
#
# 21+ /system/bin/app_process32 *5 /system/bin/app_process32_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_process64 *5 /system/bin/app_process64_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_processXX *5 /system/bin/app_process_init 0755 u:object_r:system_file:s0 required
# 21+ /system/bin/app_process (symlink to /system/xbin/daemonsu) required
# 21+ *5 /system/bin/app_process32 (symlink to /system/xbin/daemonsu) required
# 21+ *5 /system/bin/app_process64 (symlink to /system/xbin/daemonsu) required
# *5: Only do this for the relevant bits. On a 64 bits system, leave the 32 bits files alone, or dynamic linker errors
# will prevent the system from fully working in subtle ways. The bits of the su binary must also match!
#
# 17+ common/99SuperSUDaemon *6 /system/etc/init.d/99SuperSUDaemon 0755 u:object_r:system_file:s0 optional
# *6: only place this file if /system/etc/init.d is present
#
# 17+ 'echo 1 >' or 'touch' *7 /system/etc/.installed_su_daemon 0644 u:object_r:system_file:s0 optional
# *7: the file just needs to exist or some recoveries will nag you. Even with it there, it may still happen.
#
# It may seem some files are installed multiple times needlessly, but
# it only seems that way. Installing files differently or symlinking
# instead of copying (unless specified) will lead to issues eventually.
#
# After installation, run '/system/xbin/su --install', which may need to
# perform some additional installation steps. Ideally, at one point,
# a lot of this script will be moved there.
#
# The included chattr(.pie) binaries are used to remove ext2's immutable
# flag on some files. This flag is no longer set by SuperSU's OTA
# survival since API level 18, so there is no need for the 64 bit versions.
# Note that chattr does not need to be installed to the system, it's just
# used by this script, and not supported by the busybox used in older
# recoveries.
#
# ----- "SYSTEM-LESS" INSTALL -----
#
# "System-less" install requires a modified boot image (the script can patch
# many boot images on-the-fly), but does not touch /system at all. Instead
# it keeps all the needed files in an image (/data/su.img) which is mounted
# to /su. Default install method on all Android-6.0+ and Samsung-5.1+
# devices.
#
# Note that even on 6.0+, system compatibility is checked. See the "SYSTEM"
# install section above.
#
# An ext4 image is created as /data/su.img, or /cache/su.img if /data could
# not be mounted. Similarly, the APK is placed as either /data/SuperSU.apk
# or /cache/SuperSU.apk. This is so we are not dependent on /data decryption
# working in recovery, which in the past has proved an issue on brand-new
# Android versions and devices.
#
# /sbin/launch_daemonsu.sh, which is added a service to init.rc, will mount
# the image at /su, and launch daemonsu from /su/bin/daemonsu. But before it
# does that, it will try to merge /data/su.img and /cache/su.img (leading),
# if both are present. It will also try to install the SuperSU APK.
#
# Files are expected at the following places (/su being the mountpoint of
# the ext4 image):
#
# API source target chmod chcon required
#
# 22+ common/Superuser.apk /[data|cache]/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 22+ ARCH/su *1 /su/bin/su 0755 u:object_r:system_file:s0 required
# 22+ /su/bin/daemonsu 0755 u:object_r:system_file:s0 required
# *1: su.pie for 17+ x86(_32) only
#
# 22+ ARCH/supolicy /su/bin/supolicy_wrapped 0755 u:object_r:system_file:s0 required
# 22+ /su/bin/su (symlink) *2 /su/bin/supolicy 0755 u:object_r:system_file:s0 required
# 22+ ARCH/libsupol.so /su/lib/libsupol.so 0644 u:object_r:system_file:s0 required
# *2: when called this way, su sets the correct LD_LIBRARY_PATH and calls supolicy_wrapped
#
# 22+ ARCH/sukernel /su/bin/sukernel 0755 u:object_r:system_file:s0 required
#
# These files are automatically created on launch by daemonsu as needed:
# 22+ /system/bin/sh /su/bin/sush 0755 u:object_r:system_file:s0 required
# 22+ /system/bin/app_process[64] /su/bin/app_process 0755 u:object_r:system_file:s0 required
#
# These files are injected into the boot image ramdisk:
# 22+ common/launch_daemonsu.sh /sbin/launch_daemonsu.sh 0700 u:object_r:rootfs:s0 required
#
# On devices where / is in the system partition:
# 22+ ARCH/suinit /init 0750 u:object_r:rootfs:s0 required
#
# The automated boot image patcher included makes the following modifications
# to the ramdisk:
#
# - Uses the supolicy tool to patch the sepolicy file
# - Injects /sbin/launch_daemon.sh
# - Creates /su
# - Removes /verity_key
# - Patches /*fstab*
# --- Removes support_scfs and verify flags
# --- Changes forceencrypt/forcefdeorfbe into encryptable
# --- Set ro mounts to use noatime
# - Patches /init.rc
# --- Removes 'setprop selinux.reload_policy' occurences
# --- Adds a SuperSU:PATCH marker with the version of the sukernel tool
# --- Adds a SuperSU:STOCK marker listed the SHA1 of the original boot image
# - Adds /init.supersu.rc
# --- Adds a sukernel.mount property trigger that mounts /data/su.img to /su
# --- Adds the daemonsu service that launches /sbin/launch_daemon.sh
# --- Adds exec /sbin/launch_daemonsu.sh on post-fs-data
# - Patches /init.environ.rc
# --- Adds PATH variable if it does not exist
# --- Prepends /su/bin to the PATH variable
# - Patches /*.rc
# --- Adds a seclabel to services and execs that are missing one
# - In case the device has the root directory inside the system partition:
# --- /system_root contents are copied to /boot
# --- All files mentioned above are modified in /boot instead of /
# --- /boot/*fstab* is modified to mount / to /system_root, and
# bind-mount /system to /system_root/system
# --- Kernel binary is patched to load from initramfs instead of system
#
# In case this documentation becomes outdated, please note that the sukernel
# tool is very chatty, and its output tells you exactly what it is doing
# and how. In TWRP, you can view this output by catting /tmp/recovery.log
# after flashing the ZIP.
#
# The boot image patcher creates a backup of the boot image it patches, for
# future restoration. It cannot re-patch a patched boot image, it will restore
# the previous boot image first. /[data|cache]/stock_boot_*.gz
#
# The boot image patcher currently only supports GZIP compressed ramdisks, and
# boot images in the standard Android boot image format.
#
# During boot image patch, /data/custom_ramdisk_patch.sh will be called,
# with the name of the ramdisk cpio file as parameter. The script must
# replace the input file and return a 0 exit code.
#
# Just before flashing, the boot image patcher will call
# /data/custom_boot_image_patch.sh with the name of the patched boot image
# as parameter. A device-specific patcher can further patch the boot image
# if needed. It must replace the input file and return a 0 exit code.
OUTFD=$2
ZIP=$3
getvar() {
local VARNAME=$1
local VALUE=$(eval echo \$"$VARNAME");
for FILE in /data/.supersu /cache/.supersu /system/.supersu; do
if [ -z "$VALUE" ]; then
LINE=$(cat $FILE 2>/dev/null | grep "$VARNAME=")
if [ ! -z "$LINE" ]; then
VALUE=${LINE#*=}
fi
fi
done
eval $VARNAME=\$VALUE
}
readlink /proc/$$/fd/$OUTFD 2>/dev/null | grep /tmp >/dev/null
if [ "$?" -eq "0" ]; then
# rerouted to log file, we don't want our ui_print commands going there
OUTFD=0
# we are probably running in embedded mode, see if we can find the right fd
# we know the fd is a pipe and that the parent updater may have been started as
# 'update-binary 3 fd zipfile'
for FD in `ls /proc/$$/fd`; do
readlink /proc/$$/fd/$FD 2>/dev/null | grep pipe >/dev/null
if [ "$?" -eq "0" ]; then
ps | grep " 3 $FD " | grep -v grep >/dev/null
if [ "$?" -eq "0" ]; then
OUTFD=$FD
break
fi
fi
done
fi
ui_print_always() {
echo -n -e "ui_print $1\n" >> /proc/self/fd/$OUTFD
echo -n -e "ui_print\n" >> /proc/self/fd/$OUTFD
}
if [ -z "$LESSLOGGING" ]; then
LESSLOGGING=false
fi
UI_PRINT_LAST=""
ui_print() {
if (! $LESSLOGGING); then
UI_PRINT_LAST="$1"
ui_print_always "$1"
fi
}
ui_print_less() {
if ($LESSLOGGING); then
ui_print_always "$1"
fi
}
ch_con() {
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toybox chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/toolbox chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toolbox chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toybox chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/toolbox chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toolbox chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
}
ch_con_ext() {
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toybox chcon $2 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/toolbox chcon $2 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toolbox chcon $2 $1 1>/dev/null 2>/dev/null
chcon $2 $1 1>/dev/null 2>/dev/null
}
Thanks for the quick response. I have attempted to copy some of the files stated in excerpt to my system image but it seems that I might have missed a few. But I see it stating some chcon commands so I'm just wondering if it'd be possible to chcon the files needed on a linux pc and have it work.
Bythos73 said:
Thanks for the quick response. I have attempted to copy some of the files stated in excerpt to my system image but it seems that I might have missed a few. But I see it stating some chcon commands so I'm just wondering if it'd be possible to chcon the files needed on a linux pc and have it work.
Click to expand...
Click to collapse
I'm not sure what will happen if you run those chcon commands, what happened when you tried it?
Yup, this manual way may be a bit tricky
http://su.chainfire.eu/#embed said:
6. Embedding
6.1. Files
All the files you need are in the latest SuperSU flashable ZIP. The latest 'stable' build can always be retrieved from my server, for the latest 'beta' release you need to check the beta thread in the SuperSU forums.
The installation script inside the ZIP is META-INF/com/google/android/update-binary. This is not a binary as the name suggests, but a shell script, and the standard update ZIP's updater-script file is just a dummy.
This script has comments which document which files go where on which API level, and what their file permissions, ownerhips, and security labels must be. If you have done this exactly right, SuperSU will not complain when you open the app after booting.
6.2. Custom ROMs
It is non-trivial to include SuperSU exactly right on your own. It is therefore often easiest to include the latest SuperSU ZIP inside your own flashable ZIP, and chain its installation.
Click to expand...
Click to collapse
Can you tell us a bit more about your device model & android version, and which files you copied/commands you ran so far?
What errors if any do you get after flashing your modified img?
I secretly hope a custom recovery exists for your device, or porting one proves easier :fingers-crossed:
I'm repacking the image now using img2simg for my first boot attempt.
I have an Alcatel 3 5052A, Device CodeName A3A running Android Oreo 8.1.0. So far I don't believe I can get a custom recovery for this device as the line of devices that this phone was released with seem to have a bootloader which doesn't boot unsigned images, nevermind the fact that it's impossible to flash any partition other than system through fastboot. It's a real pain. Thankfully it does boot GSIs like Phh-Treble so not all hope is lost on that front.
I've copied the su and supolicy binaries, I got daemonsu by copying the su bin, I also copied the SuperSU apk and the libsupol.so library into all of their respective directories.
It has booted but no su, and SuperSU was not in the Launcher so I'm gonna retry it.
Don't give up! there are lots of avenues yet to explore if you want to give the manual method a rest for a while.
What do you get when you try unlocking the bootloader from fastboot?
Are you familiar with SP Flash tools? This is an alternative way to flash images onto various MTK devices.

Categories

Resources