Help including SuperSU and su binaries in stock ROM. - Android Q&A, Help & Troubleshooting

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.