Installing SuperSU root on Mi 5c - Xiaomi Mi 5c Guides, News, & Discussion

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

Related

[Q] Rooting a Trekstor Surftab breeze 10.1 quad [SOLVED]

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.

[GUIDE] Disable selinux to allow Xposed framework for Oneplus 2

This is a quick guide for disabling selinux to allow installation of Xposed framework on OsygenOS 2.2.x. Tested on my OPT.
This means changing the boot partition settings to allow permissive selinux and re-writing it.
It could work theoretically on any other Lollipops, perhaps Marshmallow, however... needs to be tested.
The red disclaimer: you perform all these changes at your own risk!
My current configuration:
- OxygenOS 2.2.1 (rooted, BETA-SuperSU-v2.67-20160121175247, Boeffla-Kernel 1.1-beta11)
- xposed-v80-sdk22-arm64
- mkbootimg-tools
Steps
You can use adb shell from a prompt (windows is quite ugly though).
For windows I recommend Puttytray (https://puttytray.goeswhere.com/) and connect using adb.
For future ROM updated, assuming you keep patch.sh, just use the terminal embedded in TWRP to run it right from the phone, generate the new boot image and apply it again.
Reboot in recovery (I use TWRP 3.0.0-2)
Make sure /system partition is mounted
Code:
mount /system
unzip mkbootimg_tools-master.zip
cd mkbootimg_tools-master/ARM
Create the patch.sh script (the wrapper for the mkbooting tools)
Code:
vi patch.sh
paste the contents of the attached script:
Code:
#!/system/bin/sh
############################################
# Script to alter the boot image and set selinux=permissive
# WARNING! use this at our own risk, I am not responsible for bricking your phone by corrupting the boot partition
# Tested on OxygenOS 2.1.1, 2.2.0, 2.2.1 (Lollipop 5.1.1)
#
# v1.0.2015-12-30
# Author: cr1cr1
############################################
# Mount /system partition rw, if not already mounted
mount -o rw /system 2>/dev/null
# Set some variables
ORIBOOT=ori-boot.img
PATCHEDBOOT=../new-boot.img
OUTDIR=boot~tmp
# Get the actual boot block partition
BOOTPART=`busybox readlink -f /dev/block/platform/*/by-name/boot`
if [ ! -r $BOOTPART ]; then
echo "Boot partition not found at: $BOOTPART!"
exit 1
fi
echo "Using boot partition: $BOOTPART"
# Copy the boot partition
set -x
busybox dd if=$BOOTPART of=$ORIBOOT
set +x
RETCODE=$?
if [ $RETCODE -ne 0 ]; then
echo "Failed to copy boot part using DD utility, retcode=$RETCODE"
exit $RETCODE
fi
# Unpack the boot image
set -x
./mkboot $ORIBOOT $OUTDIR
set +x
RETCODE=$?
if [ $RETCODE -ne 0 ]; then
echo "Failed to run mkboot utility, retcode=$RETCODE"
exit $RETCODE
fi
if [ ! -w $OUTDIR/img_info ]; then
echo "$OUTDIR/img_info is not writable, exiting!"
exit 1
fi
# Change the kernel command line parameters
if [ "$(busybox grep selinux $OUTDIR/img_info)" == "" ]; then
set -vx
busybox sed -i "s/cmd_line\='/cmd_line\='androidboot.selinux=permissive /" $OUTDIR/img_info
set +vx
else
set -vx
busybox sed -Ei 's/\.selinux=[^ '\'']+/.selinux=permssive/' $OUTDIR/img_info
set +vx
fi
# Repack the boot image
set -x
./mkboot $OUTDIR $PATCHEDBOOT
set +x
Set the execute permission
Code:
chmod +x patch.sh
Execute the script to patch the boot image
Code:
./patch.sh
You should now have a patched and repacked image:
new-boot.img
Install the new boot image using twrp:
- press install
- press "Install Image"
- select new-boot.img
- Select the partition "boot"
Apparently there is a need to also explicitly disable selinux on startup as well.
For this, yet another script must be used:
Code:
vi /system/etc/init.d/08customscript
Paste the following:
Code:
#!/system/bin/sh
mount -o remount,rw /system
/system/xbin/su 0 setenforce 0
echo "0" > /sys/fs/selinux/enforce
mount -o remount,ro /system
Set the appropriate permissions
Code:
chmod u=rwx,go=r /system/etc/init.d/08customscript
There isn't a plugin for kernel adiutor that does the same?
Enviado desde mi ONE A2003
Zalpa said:
There isn't a plugin for kernel adiutor that does the same?
Enviado desde mi ONE A2003
Click to expand...
Click to collapse
Probably, I have seen last night with Boeffla's kernel editor you have the option to disable Selinux.
However, this will NOT work unless you change the boot image as well.
cr1cr1 said:
Probably, I have seen last night with Boeffla's kernel editor you have the option to disable Selinux.
However, this will NOT work unless you change the boot image as well.
Click to expand...
Click to collapse
Thanks
Enviado desde mi ONE A2003

Tolino e-Reader with broken android

Hey Guys,
i got a broken Tolino Vision 3 HD from a friend to fix the issues with the android. It´s a popular ebook reader in Germany.
At the moment I got the device it stuck in language selection and the partition for the ebooks wasn´t shown after USB connection.
So I downloaded the new software version from the vendor "mytolino" (I am not allowed to post urls). I tried to update via
fastboot update
Click to expand...
Click to collapse
but i got this error:
archive does not contain 'android-info.txt'
error: update package '..\update.zip' has no android-info.txt
Click to expand...
Click to collapse
. So I unpack the .zip and try to flash the images manualy. This didn´t work. After this is tried to copy the update.zip to /sdcard via adb push but this didn´t work, too.
Question:
Is there any way to flash the device with the given update.zip?
Regards and all good wishes from sunny Germany
Did you tried to do factory reset? Are you able to boot into recovery using key-combination?
The more heavy way I used yesterday to reanimate my Tolino page after trying to install OpenGapps on them (no, did not work oO).
I am not allowed to post URL's because of "Noob-Protection" in Forum. There is a "Tolino Vision 2 rooten" howto in web. Some parts of them you can use to solve your problem.
1. Create own ADB-Enabled custom recovery (Did worked for me only with 10.0.1 update package). Should be done on Linux
Code:
$ mkdir custom_recovery
$ cd custom_recovery
$ unzip ../update.zip recovery.img
$ mv recovery.img recovery.img.orig
$ abootimg -x recovery.img.orig
$ mv initrd.img initrd.img.orig
$ mkdir initrd
$ cd initrd
$ zcat ../initrd.img.orig | cpio -vid
Adjust default.prop with values "ro.secure=0", "ro.debuggable=1" und "persist.sys.usb.config=mass_storage,adb".
Code:
$ find . | cpio --create --format='newc' | gzip > ../initrd_adb_enabled.img
$ cd ..
$ abootimg --create recovery_adb_enabled.img -f bootimg.cfg -k zImage -r initrd_adb_enabled.img
You get error : "updated is too big for the Boot Image" with new size value. Calculate this value to hexadecimal and adjust the "bootsize" in "bootimg.cfg" to hex-value
Do abootimg again.
2. Use the custom recovery to trigger update manually
Code:
$ fastboot boot ../custom_recovery/recovery_adb_enabled.img
$ adb shell
# mount -t vfat /dev/block/mmcblk0p4 /sdcard/
# exit
$ adb push update.zip /sdcard/update.zip
$adb shell
# cd /sdcard
# busybox unzip update.zip META-INF/com/google/android/update-binary -d /tmp
# busybox chmod u+x /tmp/META-INF/com/google/android/update-binary
# /tmp/META-INF/com/google/android/update-binary 3 1 /sdcard/update.zip # Update installieren
# sync && sleep 5 && sync # sicherheitshalber, wenn man dran glaubt
# reboot
Source: google for "e-reader-forum Toolino vision 2 rooten"

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.

Ramdisk changes not reflected on Android filesystem

Hey all,
I am learning how Android works and am trying to figure out how I can update the Android filesystem by extracting a ramdisk from normal boot.img, adding some files, then flashing it back. So far, I have been unsuccessful in doing this and am hoping to figure out why. Here's the steps below I have taken:
Using a Google Pixel 4a, Android 11, kernel v 4.14 (i.e. not GKI)
High level:
Extract ramdisk.cpio from boot.img using magiskboot via adb on device, modify extract contents, sent back up to magiskboot, repackaged, then flashed via fastboot.
Detailed steps:
Grab ramdisk.cpio
Code:
$ # obtain the ramdisk.cpio from magiskboot
$ adb -d shell "cd ${BOOT_IMG_PATH}; ./magiskboot unpack boot.img"
$ adb -d pull /${BOOT_IMG_PATH}/ramdisk.cpio /tmp/
$ # attempt to modify the filesystem
$ mkdir /tmp/rd && cd rd
$ cpio -i < /tmp/ramdisk.cpio
$ touch yolo
$ echo "why doest this work" > system/wtf.txt
$ echo "why doest this work" > sys/wtf.txt
$ echo "why doest this work" > vendor/wtf.txt
#patch this directory back up and send to magiskboot
$ find . | cpio -oH new > /tmp/new.ramdisk.cpio
$ adb -d push /tmp/new.ramdisk.cpio ${BOOT_IMG_PATH}/ramdisk.cpio
$ adb -d shell "cd ${BOOT_IMG_PATH}; ./magiskboot repack boot.img
$ adb -d pull /${BOOT_IMG_PATH}/new-boot.img /tmp/
# apply this modifyied boot.img
$ adb reboot bootloader
fastboot flash boot /tmp/new-boot.img
fastboot reboot
After doing this, I'll adb back in to verify:
Code:
adb -d shell "find / -name "wtf.txt" 2>/dev/null
# silence.... always silence... no file change
* I am aware that Wu modifies the extracted dtb file from boot.img with a "magiskboot dtb dtb patch" command but that doesn't seem to apply to my particular boot.img as the fstab doesn't seem to be around
* I am aware that vbmeta and codesigning, I have disabled vbmeta via fastboot
* I am aware that there's A/B slots for flashing. I have tried flashing both slots to make sure the updated ramdisk is seen
* I am aware of magiskboot's kernel patch from skip_initramfs -> want_initramfs. I could use some clarification on this if it pertains to my problem
* My Android device uses "mount method C" from Wu's great writeup https://github.com/topjohnwu/Magisk/blob/master/docs/boot.md. That is, it's init's job to mount everything on my device. I guess I feel confused as to why init wouldn't mount the additional files that I've added to the ramdisk
Extremely grateful for help or guidance on what I've overlooked. Thanks y'all
You should probably examine your modified boot file to see if the new stuff is in there.
I don't use your tools or even deal with cpio as a file type.
Code:
C:\>echo Hello > sbin\bogus
C:\>imgutil /i boot.img sbin/bogus
C:\>imgutil /l boot.img
...
sbin/bogus
...

Categories

Resources