[Android Q&A, Help & Troubleshooting] sdfsdfgdhshxzv:
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 chivin123@chivin-All-Series #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://xdaforums.com/showthread.php?t=2206421

http://xdaforums.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:

sudo apt-get install unzip build-essential

c) Extract everything and compile the ext4 utils.

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.

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):

# 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:

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

ls -Z system_root/bin/toolbox

to obtain the right value, in our case u:object_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:

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.

./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.

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

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.