How can I make changes to /system in nougat? - Huawei P9 Questions & Answers

Quick summary, I can not:
mount -o remount,rw /system in normal mode even with root permission. Error is "Device busy"
modify files in /system in twrp and keep it persistent. It somehow roll back to the stock state after reboot into normal mode.
I'm a long-time linux user, and fairly familiar with rooting in pre-nougat versions. My previous phone is Oneplus-X in LineageOS-14, and I could do whatever I like with the system partition. Recently I received a P9 as present. I updated the rom to B377 and flashed OldDroid's TWRP-3.1.0+phh su. But I can not find a way to modify the /system partition. I need to change a lot of things, like /system/etc/hosts, adding apk into /system/priv-app, etc.
Could someone help?

ccaappton said:
Quick summary, I can not:
mount -o remount,rw /system in normal mode even with root permission. Error is "Device busy"
modify files in /system in twrp and keep it persistent. It somehow roll back to the stock state after reboot into normal mode.
I'm a long-time linux user, and fairly familiar with rooting in pre-nougat versions. My previous phone is Oneplus-X in LineageOS-14, and I could do whatever I like with the system partition. Recently I received a P9 as present. I updated the rom to B377 and flashed OldDroid's TWRP-3.1.0+phh su. But I can not find a way to modify the /system partition. I need to change a lot of things, like /system/etc/hosts, adding apk into /system/priv-app, etc.
Could someone help?
Click to expand...
Click to collapse
Hopefully this might help:
1. revert back to unmodified boot image (in TWRP flash from here[/URL or restore your backup from the unmodified boot image] , leave anything else untouched (especially TWRP 3.1.0-0 for EMUI 5)
2. flash this [URL="https://forum.xda-developers.com/showpost.php?p=71588837&postcount=102"]SuperSU image in TWRP (read the comments in the post please ... single bootloop ... then everything is ok and rooted)
3. install JRummy's BusyBox from Google Play (Stephen's won't work)
You are done and good to modify /system.
Note: resulting earthquakes, thunderstorms and spring floods from this work are solely under your own responsibility :laugh:

hakaz said:
Hopefully this might help:
1. revert back to unmodified boot image (in TWRP flash from here[/URL or restore your backup from the unmodified boot image] , leave anything else untouched (especially TWRP 3.1.0-0 for EMUI 5)
2. flash this [URL="https://forum.xda-developers.com/showpost.php?p=71588837&postcount=102"]SuperSU image in TWRP (read the comments in the post please ... single bootloop ... then everything is ok and rooted)
3. install JRummy's BusyBox from Google Play (Stephen's won't work)
You are done and good to modify /system.
Note: resulting earthquakes, thunderstorms and spring floods from this work are solely under your own responsibility :laugh:
Click to expand...
Click to collapse
1. I did a backup of boot partition before phh root, so should be able to restore the backup, instead of download the boot partition from others?
2. Is systemless supersu binaries need be individualized for every phone? Can I download systemless supersu from somewhere more semi-official? I'm not exactly comfortable installing zips from random links. ()

Ad 1. Till now rooting on our P9 works through injection of the su mounting routine into the kernel in boot section (if using a modified kernel + su installation or modifying the kernel during su installation itself doesn't make a difference). So any su installation modifies the boot section and you mess things up if you try to install another su on top of the other. Therefore reverting to the original boot image is mandatory before installation of another su.
Ad 2. The su is compiled against different platforms​ not phones (in our case arm64). So @Chainfire has the different platform variations in his package. The "shady" package in our case is basically the v2.79 stable version of 12/20 2016 (you can unpack both packages and compare them against each other, they are bit for bit equal) but has an P9 specific injection routine to modify the kernel. After installation you have pure su v2.79 stable on board - not more, not less.
Sorry, "normal" SuperSU packages won't work due to lacking the kernel modification (phh uses a modified kernel instead you have to flash separately on P9).
Cheers!

hakaz said:
Ad 1. Till now rooting on our P9 works through injection of the su mounting routine into the kernel in boot section (if using a modified kernel + su installation or modifying the kernel during su installation itself doesn't make a difference). So any su installation modifies the boot section and you mess things up if you try to install another su on top of the other. Therefore reverting to the original boot image is mandatory before installation of another su.
Ad 2. The su is compiled against different platforms​ not phones (in our case arm64). So @Chainfire has the different platform variations in his package. The "shady" package in our case is basically the v2.79 stable version of 12/20 2016 (you can unpack both packages and compare them against each other, they are bit for bit equal) but has an P9 specific injection routine to modify the kernel. After installation you have pure su v2.79 stable on board - not more, not less.
Sorry, "normal" SuperSU packages won't work due to lacking the kernel modification (phh uses a modified kernel instead you have to flash separately on P9).
Cheers!
Click to expand...
Click to collapse
Thanks buddy! I flashed systemless supersu, and stucked in infinite bootloop(it is only once in your post), probably because my model is EVA-AL00. I have to restore the previous boot.img.

ccaappton said:
Quick summary, I can not:
mount -o remount,rw /system in normal mode even with root permission. Error is "Device busy"
modify files in /system in twrp and keep it persistent. It somehow roll back to the stock state after reboot into normal mode.
I'm a long-time linux user, and fairly familiar with rooting in pre-nougat versions. My previous phone is Oneplus-X in LineageOS-14, and I could do whatever I like with the system partition. Recently I received a P9 as present. I updated the rom to B377 and flashed OldDroid's TWRP-3.1.0+phh su. But I can not find a way to modify the /system partition. I need to change a lot of things, like /system/etc/hosts, adding apk into /system/priv-app, etc.
Could someone help?
Click to expand...
Click to collapse
Same here with Oneplus 3T.
I just posted in another post (Google Pixel).
There I just guess it was a new encription way, now Im sure, all three devices with Android 7.1.1.....

Related

[WIP][2016.01.21] Android 6.0 Marshmallow [CLOSED]

All discussion should go the SuperSU BETA thread
Attached find modified boot.img for the Nexus firmwares released so far. Together with SuperSU v2.50+ these allow root with SELinux in Enforcing mode.
These are the stock boot images from Google, with the ramdisk modified as follows:
- patched sepolicy
- disabled dmverity (if applicable)
- disabled forceencrypt (if applicable)
Rooting procedure:
- flash/upgrade to Marshmellow
- flash modified boot.img
- flash/boot TWRP and sideload latest v2.50+
Acquiring root without modifying the boot images is still under investigation. Please note that the current method will not be officially supported. Future roots may require a clean system: we are at a very early stage of root for 6.0, methods used are subject to change.
For the modders, you can do the sepolicy modifications yourself as follows:
- root a reference device (4.4+ with SELinux enabled) with v2.50+
- extract the sepolicy file from the target boot image's ramdisk
- with the reference device connected to ADB:
Code:
adb push sepolicy /data/local/tmp/sepolicy
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out"
adb shell su -c "chmod 0644 /data/local/tmp/sepolicy_out"
adb pull /data/local/tmp/sepolicy_out sepolicy_out
- replace the sepolicy file in the boot image's ramdisk with the sepolicy_out file
- profit
(this trick should also work on the Samsung 5.1.1 kernels that people are having issues with lately)
Fugu requires v2.51+
EXPERIMENT: Root without modifying /system
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Idea
To have root on modern Android versions, we need our files to be executable and our daemon to be started on boot. We normally do this by making modifications to /system, tapping into binaries and scripts executed by init. If we're also modifying the boot image, then we should be able to do all this without modifying system at all. A benefit of this is that it makes OTAs easier - reflashing the boot image is less hassle than reflashing system.
As the binaries should still be updatable, and we don't know the space we have available in the boot image itself, we're mounting a (writable) ext4 image with /su as mount point from /data, and modifying PATH accordingly. Interestingly, for reasons yet unknown to me, if the image is mounted r/o by init, later remounting it r/w causes a bunch of issues. So we're keeping it r/w (for root) for now.
An overlayfs/unionfs solution would be even more ideal, transparently placing files in /system without modifying the actual partition, but I have not been able to find one that is (a) compatible with all Android architectures and (b) not kernel dependent and (c) not GPL - or even just one of those requirements, really. It's technically all possible, it just needs to be done.
Caveats
- Apps with hardcoded paths to su (seriously?) will bork
- Factory reset unroots
- Factory reset wipes pin
- ...
- Bugs... Bugs everywhere!
Instructions
You must absolutely re-flash your stock /system partition, or the separate root instances will interfere with eachother. The installer for this experiment will not clean up old root files.
- Flash stock /system (and /vendor and /oem, if present)
- Flash the attached boot image
- Flash the attached SuperSU ZIP in TWRP
Ramdisk modifications
- include (post above this one)
- init.rc (devs: please open file for reference)
--- on init
------ mkdir /su ...
--- on post-fs-data
------ copy image from cache to data (for rooting without access to /data in custom recovery)
------ mount image to /su
--- service daemonsu
- init.environ.rc
--- export PATH, prepended with /su/bin
- file_contexts
--- /su(/.*)? ubject_r:system_file:s0
NOTE
- Not all SuperSU options are supported yet in this mode
- I have not tested with encrypted devices
- /system should never be remounted r/w, I hope I didn't miss anything here
- Root with modifying /system is also still operational. I can't predict what the exploiters will need.
- I'm not sure where we're going with this. Future roots may require a clean system.
BETA-SuperSU-v2.56-20151030013730.zip
Changes
(The changelogs for the specific SuperSU versions can be found here: http://forum.xda-developers.com/showpost.php?p=23427824&postcount=3)
2016.01.21
- v2.67 ZIP
2016.01.03
- v2.66 ZIP
2015.12.26
- v2.65 ZIP
2015.12.20
- v2.64 ZIP
2015.12.11
- v2.62-3 ZIP:
--- (systemless) ZIP: Fix calling wrong script name for custom patcher script
--- (systemless) ZIP: Improve APK overwrite
--- (systemless) ZIP: Do not move backups from /cache to /data, just copy them
(there are no changes to SuperSU itself compared to v2.62, just minor script changes in the ZIP)
2015.12.10
- v2.62 ZIP
2015.12.07
- v2.61 ZIP
2015.12.05
- v2.60 ZIP with automated boot image patcher
2015.10.30 #2
- Added systemless root experiment for other Nexus than hammerhead
2015.10.30
- Added systemless root experiment for hammerhead
2015.10.28
- Added Angler kernel
- Added Razor mra58u kernel
2015.10.20
- Added Bullhead kernel
2015.10.08
- New image for Fugu, requires v2.51
2015.10.07
- New images, should fix the factory reset issues some users with encrypted data were seeing
EXPERIMENT: Root without modifying /system #2: Automation
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Continuing on the previous post, here is SuperSU v2.62 BETA, with automated boot image patching. It's been tested by myself on various Samsung's running anything from 4.3 to 5.1, and all of the recent Nexus devices on 6.0. Even on CM13. Other users have tested it with success on various other devices.
If you are coming from any SuperSU install in /system, you must re-flash the stock system (and vendor and oem, if present) partition contents prior to installing this.
If you are coming from a SuperSU 2.56 system-less install, you must re-flash the stock boot image prior to installing this.
If you are coming from a SuperSU 2.60 system-less install, or were not rooted at all, then you can just flash the ZIP without any special prior instructions.
If TWRP offers you to keep /system read-only, indeed keep it read-only.
If TWRP tells you SuperSU is not installed, and asks you to install it, do not do it, you will break things!
If on Android 6.0 or Samsung 5.1, the ZIP installer will install SuperSU in systemless mode and patch the boot image. The boot image patcher currently only supports gzip compressed ramdisks and the standard Android boot image format. Some devices do not use the standard format, and many custom kernels use a compression other than gzip. A backup is made (/data/stock_boot_<sha>.img.gz) of the original boot image before patching it.
Further implementation details (including an updated list of changes to the ramdisk) are explained in the installer script itself, as usual.
Notes on 2.62+
A poor man's overlay is used on /system/xbin. We are creating a copy of /system/xbin in /su/xbin_bind, adding a symlink to /su/bin/su there, then mounting the entire thing on top of the original /system/xbin. This is likely to fix some compatibility issues with some apps, without actually modifying /system. Removing /su/xbin_bind and rebooting will disable this feature, or "echo BINDSYSTEMXBIN=false>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash.
If you have one of those devices that refuse to remount system r/w in Android such as the Nexus 6P, but you do want to do this, "echo FSTABSYSTEMRW=true>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash will patch the boot image in such a way that remounting will work. This feature itself breaks OTA compatibility, regardless of if you end up writing to /system or not.
Both of these features are likely temporary.
Notes on 2.64+
There have been a lot of changes to the ZIP installer. Hopefully they won't break a lot of installs. If 2.64 works well, it is likely to be promoted to the "main beta" in place of 2.52, and the How-To SU document will be updated with the relevant information.
A major change in setup is that the ZIP installer will try to detect 6.0 firmwares that can be rooted without doing a systemless install. In other words, a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu").
This may catch (a) firmwares that allow sepolicy reloading from /data but have a locked bootloader and (b) custom firmwares setup to handle this. Regarding the latter, while it is not as clean as systemless, those running custom firmwares are more likely to want to modify /system anyway, it is less likely to mess with updates to those firmwares, and it prevents the necessity of reflashing the ZIP after each kernel switch. Of course, the kernel's SELinux policies must support this! See this thread for details for devs.
Notes on 2.65+
As 2.65 adds /su/xbin, I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Notes on 2.67+
I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Downloads
BETA-SuperSU-v2.60-20151205163135.zip
BETA-SuperSU-v2.61-20151207213702.zip
BETA-SuperSU-v2.62-20151210170034.zip
BETA-SuperSU-v2.62-2-20151211155442.zip
BETA-SuperSU-v2.62-3-20151211162651.zip
BETA-SuperSU-v2.64-20151220185127.zip
BETA-SuperSU-v2.65-20151226141550.zip
BETA-SuperSU-v2.66-20160103015024.zip
BETA-SuperSU-v2.67-20160121175247.zip
The latest WIP version has become the main BETA version.
For all intents and purposes, this thread is closed. It will be cleaned up and unstickied in good time.

[MM] [Flashable] Patcher to provide root access without /system modification

This patcher is now outdated. Use the new SuperSU instead. http://forum.xda-developers.com/showpost.php?p=64161125&postcount=3
This zip is a systemless version. That means that you'll get root and be able to use it normally, but your system partition will not be modified, like in normal root methods. Only for Marshmallow.
Keep reading for disadvantages and advantages
Chainfire had released a newer version of his SuperSU that doesn't need to modify the system partition to provide root access. This method doesn't have much of a practical application right now, but it allows you to flash OTA updates without having to unroot or flash the stock system partition.
HOW TO USE:
If you have rooted before, flash the system partition (or reinstall the ROM) before flashing this zip.
Download the attached zip, and flash it from a recovery (I tested it with TWRP).
Download SuperSU 2.56 from here: http://forum.xda-developers.com/showpost.php?p=63197935&postcount=2 (Just download the apk)
Reboot to TWRP. If it asks you whether you want system to be mounted as r/w, and if you want to take OTAs later, choose to keep system read-only (this will replace TWRP with stock recovery on reboot).
Flash SuperSU-v2.56-20151030013730.zip
Reboot
TWRP will say that you are not rooted, just ignore that. Do not tell it to root it.
This will work with all Marshmallow kernels, even the stock kernel.
Drawback : A factory data reset will remove superuser privileges. If that happens, simply flash SuperSU-v2.56-20151030013730.zip again.
TO RECEIVE OTA UPDATES :
Just make sure not to do anything that modifies /system. For example, no build.prop changes, and no system app removal. Or even if you do these, make sure to undo these changes before flashing an OTA. You can flash OTAs without unrooting now.
Flash the stock boot.img for your current Android version before flashing OTAs.
BUGS :
I didn't find any, yet, but Chainfire wrote the following on his thread:
Apps with hardcoded paths to su (seriously?) will bork
Factory reset unroots
Factory reset wipes pin
...
Bugs... Bugs everywhere!
ADDITIONAL INFO :
This zip will replace sepolicy as mentioned on Chainfire's thread (thanks to @metaspook for the patched sepolicy, which I extracted from his zip), so you'll be able to get root access even on SELinux enforcing kernels (only the stock MM kernels right now). Also, you can flash any other kernel (as long as it comes in a zip format, not as an img) before or after flashing this, and you'll still have root access.
out386 said:
Chainfire had released a newer version of his SuperSU that doesn't need to modify the system partition to provide root access. This method doesn't have much of a practical application right now, but it allows you to flash OTA updates without having to unroot or flash the stock system partition.
HOW TO USE:
Download the attached zip, and flash it from a recovery (I tested it with TWRP).
Download SuperSU 2.56 (or newer, if it supports systemless mode) from here: http://forum.xda-developers.com/showpost.php?p=63197935&postcount=2 (Just download the apk)
Flash SuperSU-v2.56-20151030013730.zip
Reboot
This will work with all Marshmallow kernels, even the stock kernel.
Drawback : A factory data reset will remove superuser privileges. If that happens, simply flash SuperSU-v2.56-20151030013730.zip again.
TO RECEIVE OTA UPDATES :
Just make sure not to do anything that modifies /system. For example, no build.prop changes, and no system app removal. Or even if you do these, make sure to undo these changes before flashing an OTA. You can flash OTAs without unrooting now.
Flash the stock boot.img for your current Android version before flashing OTAs.
BUGS :
I didn't find any, yet, but Chainfire wrote the following on his thread:
Apps with hardcoded paths to su (seriously?) will bork
Factory reset unroots
Factory reset wipes pin
...
Bugs... Bugs everywhere!
ADDITIONAL INFO :
This zip will replace sepolicy as mentioned on Chainfire's thread (thanks to @metaspook for the patched sepolicy, which I extracted from his zip), so you'll be able to get root access even on SELinux enforcing kernels (only the stock MM kernels right now). Also, you can flash any other kernel (as long as it comes in a zip format, not as an img) before or after flashing this, and you'll still have root access.
Click to expand...
Click to collapse
Well done bro!
I'm just waiting for this
Help regarding installation
I am using MicroMax Android One with Marshmallow
Currently, I've not tired the phone.
When I open recovery, I see some options like Apply update from SD card, mount, cache wipe, factory reset, etc.
So which option should I use to flash the zip file.
out386 said:
Chainfire had released a newer version of his SuperSU that doesn't need to modify the system partition to provide root access. This method doesn't have much of a practical application right now, but it allows you to flash OTA updates without having to unroot or flash the stock system partition.
HOW TO USE:
Download the attached zip, and flash it from a recovery (I tested it with TWRP).
Download SuperSU 2.56 (or newer, if it supports systemless mode) from here: http://forum.xda-developers.com/showpost.php?p=63197935&postcount=2 (Just download the apk)
Flash SuperSU-v2.56-20151030013730.zip
Reboot
This will work with all Marshmallow kernels, even the stock kernel.
Drawback : A factory data reset will remove superuser privileges. If that happens, simply flash SuperSU-v2.56-20151030013730.zip again.
TO RECEIVE OTA UPDATES :
Just make sure not to do anything that modifies /system. For example, no build.prop changes, and no system app removal. Or even if you do these, make sure to undo these changes before flashing an OTA. You can flash OTAs without unrooting now.
Flash the stock boot.img for your current Android version before flashing OTAs.
BUGS :
I didn't find any, yet, but Chainfire wrote the following on his thread:
Apps with hardcoded paths to su (seriously?) will bork
Factory reset unroots
Factory reset wipes pin
...
Bugs... Bugs everywhere!
ADDITIONAL INFO :
This zip will replace sepolicy as mentioned on Chainfire's thread (thanks to @metaspook for the patched sepolicy, which I extracted from his zip), so you'll be able to get root access even on SELinux enforcing kernels (only the stock MM kernels right now). Also, you can flash any other kernel (as long as it comes in a zip format, not as an img) before or after flashing this, and you'll still have root access.
Click to expand...
Click to collapse
Good work n thanks for mention bt can't understand why u created a patcher again where I'v already created one!
Its ok, good job.
Good.... Thanks for posting
metaspook said:
Good work n thanks for mention bt can't understand why u created a patcher again where I'v already created one!
Its ok, good job.
Click to expand...
Click to collapse
Yes, well, I would never have reposted the same thing, so, I'm sorry if it seemed like that.
This one uses Chainfire's new systemless root method. Unlike other root methods that need modifications to /system, this method uses modifications to the boot image to set up and run the su daemon from a loop device on the /data partition and achieve root. Right now, that doesn't have much of an advantage except to make flashing OTAs easier. Chainfire made it because future devices might need it. I made the patch because someone on FB asked about it.
<accidental double post, sorry. Can't delete>
kalpitandroid said:
I am using MicroMax Android One with Marshmallow
Currently, I've not tired the phone.
When I open recovery, I see some options like Apply update from SD card, mount, cache wipe, factory reset, etc.
So which option should I use to flash the zip file.
Click to expand...
Click to collapse
You need to install a custom recovery first. Go to the Android One (First generation) General forums on this site. You'll find a how-to at the very top of the list of threads. Once you have a custom recovery, flash this using the "install zip" option.
out386 said:
Yes, well, I would never have reposted the same thing, so, I'm sorry if it seemed like that.
This one uses Chainfire's new systemless root method. Unlike other root methods that need modifications to /system, this method uses modifications to the boot image to set up and run the su daemon from a loop device on the /data partition and achieve root. Right now, that doesn't have much of an advantage except to make flashing OTAs easier. Chainfire made it because future devices might need it. I made the patch because someone on FB asked about it.
Click to expand...
Click to collapse
Hmm... gotcha now.. Good work!
If u ever need any help just pm.
Thank you...
out386 said:
<accidental double post, sorry. Can't delete>
Click to expand...
Click to collapse

[KERNEL][M 6.0] US Unlocked / Developer Edition [Normal/Systemless Root][03 DEC 2015]

**** The posted systemless kernel is only compatible with SuperSU 2.56!!! ****
*** Starting with SuperSU 2.60+ kernel can now be auto-patched for systemless root. ***
**As of 06 December 2015 flar2 has released ElementalX 6.02 for Sense Marshmallow **
* If you still desire a stock kernel with systemless root but want to use newer SuperSU see below *​
Messed around with the boot.img from today's Marshmallow update and have made it compatible with systemless root.
Systemless root in general is experimental and so is the kernel. I've literally just made it and tested it enough to that it boots and apps are able to be granted root access, so flash at your own risk.
Kernel has been running without issue.
Other than systemless root compatibility, this kernel is completely stock and no other modifications made.
Intructions - Systemless:
Download kernel from here.
Download SuperSU 2.56 beta from this post (only one that works with this method of root).
Copy both to phone
Flash the image directly using TWRP (toggle from ZIP to IMG under install)
Immediately flash SuperSU-v2.56-20151030013730.zip afterwards.
Reboot
TWRP will notify of no SU when you reboot, click DO NOT INSTALL as TWRP needs to be updated to detect this root method (it only looks in /system)
Instructions - Traditional:
Download kernel from here.
Download SuperSU 2.52 beta from this thread (it's the M compatible version)
Copy both to phone
Flash the image directly using TWRP (toggle from ZIP to IMG under install)
Immediately flash BETA-SuperSU-v2.52.zip afterwards.
Reboot
Keeping stock kernel with updated SuperSU:
If you prefer running the stock kernel with systemless root and want to stay current on SuperSU versions you need a stock kernel when you update SuperSU. When SuperSU installs it tries to restore a backup it made of your boot.img from the last time SuperSU was installed. Since this was made before auto patching there won't be a backup. Also, in newer versions it detects if your device needs systemless or if it can modify /system. If TWRP hasn't been told to keep system read-only it will likely default to a /system install. So, if you want to keep stock kernel and systemless root there are two things you are going to need:
Stock Kernel: You can actually use the kernel provided for traditional root as a stock kernel for the purpose of these instructions.
Systemless Override: To guarantee that SuperSU gives you the systemless install over /system you need to create a file called ".supersu" with the line "SYSTEMLESS=true" and place it in /data in TWRP before you install (eg. /data/.supersu). Alternatively, you can download this one (extract from the ZIP and place in /data).
When the file is placed in /data flash the boot.img in TWRP and then flash SuperSU. It will make a backup when it installs so don't remove it as it will look for this backup again when you install an updated version.
Note: These are only to tide us over until HTC releases source allowing awesome devs like flar2 to work their kernel magic.
Not checked yet, but is systemless the only way to do it on 6.0 ?
Electronic Punk said:
Not checked yet, but is systemless the only way to do it on 6.0 ?
Click to expand...
Click to collapse
No, you can still do it by modifying /system, but Marshmallow made it so kernels had to be modified as well to allow root. @Chainfire took it a step further, since we already have to modify the boot.img we can modify it a little more and remove the need to alter /system and make it easier to accept OTA updates. The link I put in the OP explains it a little more, but here it is again.
Added root modified kernel for using "traditional" (modifies /system) root to the OP along with link to current Marshmallow compatible SuperSU.
I'm trying to do a systemless root. Just to confirm, I should flash the latest TWRP. Then from there flash the kernel then SuperSU both through TWRP?
mcta said:
I'm trying to do a systemless root. Just to confirm, I should flash the latest TWRP. Then from there flash the kernel then SuperSU both through TWRP?
Click to expand...
Click to collapse
If you still have stock kernel and no root you can just flash the latest SuperSU (v2.65).
If you're systemless already but don't have a backup you need to flash a boot.img that isn't already systemless modified as SuperSU will abort the install.
You can't flash the one in the OP for traditional (modifies /system) root and it will patch that one, but unless your set your /system partition to read-only, it will install using traditional root (this is the case with any unmodified boot.img not just this one because it's modified for traditional root). To make sure SuperSU installs using systemlesss you need to place the mentioned .supersu file in /data/ o make sure system is read-only in twrp. You also want to use latest SuperSU.
Just make sure you don't let TWRP install it's own SuperSU package that it includes. TWRP by default can't detect systemless root installs, so each time you reboot from TWRP it will warn that there is no root access on the device. It is important you make sure to click DO NOT INSTALL.
If you don't want to be bugged with the no root message in TWRP you can download this version which has the incompatible SuperSU package removed disabling the root check.
HAHAHAHAHA!!!!! Silly me...... it was written up there......
mcta said:
I'm trying to do a systemless root. Just to confirm, I should flash the latest TWRP. Then from there flash the kernel then SuperSU both through TWRP?
Click to expand...
Click to collapse
Okay, hopefully this is a stupid question, but I want to be sure before I flash something to boot.
I followed the instructions before the later versions of SuperSU betas came out, so I have the above linked custom boot image, but would like to be able to update to later versions. Can I safely assume that the boot_signed.img file I pulled out of ROM.ZIP in the Developer Edition Marshmallow RUU is the correct "stock" bootloader? Note that I ran the RUU, let it pause on accepting the license, then pulled the ROM.ZIP out of the temp folder to extract the binary.
Hi! Im pretty much new to rooting and I was wondering does the phone have to be S-OFF or S-ON. If it has to be S-OFF, how do you do it?
Thank you for help!

[ROOT][Kernel][TWRP] repack of the stock kernel with dm-verity and SONY RIC off

Changelog:
V5.23 Fix for Android 6 (Freeze on boot logo)
Installation of kcal kernel module for supported kernels. Get the app from https://forum.xda-developers.com/android/software-hacking/dev-kcal-advanced-color-control-t3032080
V5.22 Bug in the vendor overlay creation. Existing directories (like /vendor/bin) have not been replicated correctly
V5.21 Fix issue when running on Linux (some CR/LF)
Patch libsepol in bootimg for backwards compatibility with Android 6
V5.20 Support for superuser as an alternative to SuperSU (https://github.com/phhusson/Superuser)
Fix for the missing internal storage link in TWRP
V5.11 Support for Android 7.0
Fix in the overlay layout which could prevent some libraries from loading and cause battery drain
V5.1 Support for Android 7.0
Updated bootimg to deal with Android 7.0 policies
New tool inside bootimg for adding new contexts to binary file contexts
New system overlay layout due to a more restrictive linker in Android 7
V5.0 New system overlay method using the /vendor directory. As this directory is also in the library search path even libraries can be easily replaced without modifying the system partition
System-less SuperSU integration improved (Version 2.76 or higher recommended)
System-less xposed integration (using the standard distribution)
Support for 32.A.0.253
V4.51 Fix for awk script for Linux kernel version detection when running on Linux
V4.5 Fixed adb and mtp file access in TWRP for 32.2.A.0.224
V4.42 Added support for Z2 (Sirius) and TWRP fstab fix for leo and aries (thanks to waleedsq81)
V4.41 Fixed issue with Y/N choice on non-english Windows. Added support for Z3 (leo)
V4.4 Support for Z3+/Z4, Tablet Z2, Tablet Z3 and Tablet Z4 added (Z4 still has an issue with TWRP, but DRM fix works)
SuperSU integration reworked in order to need less SELinux exceptions and to be more secure
All tasks can now be individually selected. Therefore there is no separate DRM only script required
V4.31 Renabled Z5P (satsuki) and Z5C (suzuran) for TWRP and drmfix
V4.3 Support for older Lollipop added
Script execution for Linux fixed
V4.24 Fix for for a bug in SuperSU integration in V4.23
V4.23 Fix for repacking 3rd party kernel (Some permissions were on custom directories were lost)
V4.22 Bugfix for readta (flash_dk reported unit not)
V4.21 Fix for the Linux binary of bootimg
V4.2 Updated TWRP to 3.0.2
V4.1
Fix for WideWine (if you have your device key) Thanks a lot to goofnorf101 for testing
unpackinitfs and makeinitfs in my bootimg tool now maintain date/time of files correctly
Automatic SuperSU installation
V4.0
Fix for older kernels (Lollipop)
Binary for Linux (The older version had the ARM version packaged)
Device is not stored in the kernel image anymore
TWRP updated to version 3.0.1
FAQ - Please read
Is is possible to have root with locked bootloader?
Short answer: no
Long answer: The locked bootloader only boots unmodified kernel packages signed by Sony. The stock kernel only mounts unmodified /system partitions (dm-veritiy) -> No modification without unlocking
So any change to the kernel (like this script) or system partition requires unlocked bootloader
What is dm-verity?
A hash checksum on all blocks of a filesystem in order to verify the integrity
What is Sony RIC?
A protection to avoid mounting the root filesystem or system read/write
What happens if I unlock my bootloader
The device key (TA unit 0x1046b) will be wiped, which deactives everything DRM related. In addition a full wipe of your phone will be perfomed.
So extract your TA partition before with this great tool http://forum.xda-developers.com/crossdevice-dev/sony/iovyroot-temp-root-tool-t3349597 from zxz0O0
If you already unlocked the bootloader before, then at least the credentials will be restored, which will reactivate stuff like x-reality and camera de-noise
Why do I need to flash my device key?
Without your device only some functions can be reactivated, like x-reality. Other functions like widevine do not work with out your device key.
How do I enter TWRP recovery?
Restart your phone and press the volume key up as soon as the LED switches to yellow
I want to use a custom kernel with the DRM fix
Just say "N" to all other options. Nevertheless be prepared for problems if the custom kernel does not match your Android version.
What should I do if there is an update to this script?
First check if you really need to run this update by checking the changelog. E.g. if it says binary for Linux fixed and you are using Windows then probably you don't care. If you did not change your Android version then all you have to do is to update the kernel package with fastboot flash boot. If you do not use the automatic SuperSU integration then you have to reinstall SuperSU in TWRP.
This tool repacks an existing kernel package (usually the stock kernel) in order to make it rootable and adds TWRP recovery as well. Version 4 has been succesfully tested with LP and MM.
In particular it adresses the following issues:
DM-Verity: Android is now using dm-verity to verfy the integrity of the system partition. Until you switch it off your phone won't boot after modifying /system
SONY RIC: RIC is blocking the write access to the system partition
DRM Keys: After unlocking the bootloader your device key is wiped, which deactivates some functionaliy. E.g. x-reality, denoise in camera aso.
Recompiling the kernel is not required as only the init ramdisk needs to be modified. You can run these scripts either in Windows or Linux.
Thanks to the excellent work of zxz0O0 you can now backup the TA partition before unlocking the bootloader with this tool http://forum.xda-developers.com/crossdevice-dev/sony/iovyroot-temp-root-tool-t3349597
If you managed to backup your TA partition before you unlocked the bootloader then this version will fully reactivate your keys as well. (many thanks to addicted1900 for helping me with the testing)
As there has been some confusion I would like to point out one more time that you cannot run any kernel package which is not signed by Sony without unlocking the bootloader. So this works only with unlocked bootloader.
As it seems that it is not clear to everyone I also want to mention that <...> is a placeholder. E.g. <extracted kernel> means that you should replace it with then name of your extracted kernel, which could be kernel.elf
There was a report that having SuperSU in the system partition installed may lead to a bootloop. Therfore you shoud first install the bootimage created by this script and then install SuperSU afterwards, as it will then use the system-less strategy.
In order to use these scripts you need the kernel boot image of your current version. There two different ways to obtain it:
Method1:
If you have a .ftf image then open it with zip application (7Zip, WinZip, Windows Compressed Folder) and extract kernel.sin. Afterwards use Flashtool -> Tools -> SIN Editor to extract the kernel. You should end up with the boot image with extension .elf.
Method2:
Run your favourite recovery and connect via
Code:
adb -d shell
Now run
Code:
find /dev -name boot
dd if=<output of the find command before> of=/sdcard/kernel.img
Once you have the kernel image you are ready to use the script.
The newest version support superuser as an alternative to SuperSU. This is available open source and can be verified. In order to integrated you need the current superuser.zip from http://superuser.phh.me/superuser.zip and to be install the app afterwards from Google Play (look for superuser phh) or build it yourself from github.
To integrate the kernel part just place superuser.zip in the rootkernel directory.
You can also still use SuperSU, although it is causing a huge battery draining on my Z5 with Android 7.0 If you place SuperSU in the same directory (SuperSU*.zip, case sensitive) then it will be also installed automatically . It did all the tests with 2.76, but newer versions should work as well. Please be aware that you can not update SuperSU within the application. For a newer SuperSU version you need to rerun the script.
If you want to integrate xposed as well just place the distribution for you device and Android version in the same directory. (e.g. xposed-v86-sdk23-arm64.zip). Only support with Android 6.0 (sdk 23) and higher.
xPosed for Android 7.0+ is still not available.
Code:
rootkernel <extracted kernel> boot.img
You are prompted for several choices:
Sony RIC is enabled. Disable?
I prefer not to disable it in order to keep my phone more secure. Unfortunately there are a lot of bad guys in this world and SELinux and RIC still can save us if someone discovers a new kernel exploit.
Sony RIC basically prevents mounting the /system partition for write. You can still modify it in recovery of of course, but if you require write access to /system without entering recovery then you need to disable it.
Install TWRP recovery? Here you should say yes unless you are trying to patch a non-stock kernel, which comes already with a recovery
Install busybox? For security reasons I prefer not to install. In recovery you have it anyway. This choice is only available if you chose install TWRP
Found SuperSU-v....zip. Install? Integrates SuperSU. For this option to show up you have to place the SuperSU package into the same directory with the name SuperSU*.zip (case sensitive)
Found superuser.zip. Install? Integrates superuser. For this option to show up you have to place superuser.zip into the same directory (case sensitive)
# Make su permissive (Permits any action as su)? This only appears if you install superuser. Permissive means you can anything as root, without it is restricted mainly to file operations (sufficient for e.g. Titanium Backup)
Found xposed-v....zip. Install? Integrates xposed system-less. For this option to show up you have to place the xposed for your device and Android version into the same directory. (e.g. xposed-v86-sdk23-arm64.zip)
Install DRM fix? Installs the DRM fix. First it tries to use the device key which you flashed with flash_dk. If it does not exist it uses an alternative method which cannot fix everything (e.g. Widevine will not work, but X-reality, Camera denoise etc. will work)
Now put your phone into fastboot mode (Volume Up + connect USB) and then run:
To test it without actually flashing it:
Code:
fastboot boot boot.img
For flashing it:
Code:
fastboot flash boot boot.img
If you managed to backup for TA partition before then you can reactivate your original device key as follows:
Code:
flash_dk <ta backup image> DK.ftf
Flashing this file with flashtool will write your device key to an alternative unit, from where the drmfix library will pick it up.
This is a one-time task. It will survive a complete reset of the phone or Android system upgrade. The device key has a length of just 16 bytes, so it is correct that the resulting DK.ftf has a size of only aprox. 500 bytes.
If you like my work you can buy me a coffee
Some background information:
There are two main tools involved (for both Android and Windows)
- busybox
Probably everyone knows it
- bootimg
A multicall binary with several tools for unpacking and packing the boot image as well as adapting the SELinux policy. Part of the code is written by me from scratch, some other parts are cherry picked from other projects. I will also provide the source for it. As Windows doesn't have softlinks I modified the tools for unpacking and packing the init ramdisk to write text files with __lnk__ at the end instead.
Would be great if someone shared E6653 stock .200 kernel boot.img or flashable zip so we can try this out
Funkmasterchilla said:
Would be great if someone shared E6653 stock .200 kernel boot.img or flashable zip so we can try this out
Click to expand...
Click to collapse
Do you want the kernel.sin of stock . 200?
lordriguez said:
Do you want the kernel.sin of stock . 200?
Click to expand...
Click to collapse
I am downloading the whole firmware again from xperifirm. Thank you mate !
Edit: Working great! I'll stick to stock kernel now since Androplus' consumes more battery while asleep !
Edit2: I successfully flashed recoveries in command window from my PC but can't access TWRP at boot though, no LED flashing.
Edit3: Ok that's cuz there's no recovery boot script obviously, my bad. That's above my pay grade, if somebody is kind enough to create a stock. 200 with recoveries it'd be much appreciated PM me if so
Edit!: I flashed monx new stock based kernel
Thank you Tobias !
tobias.waldvogel said:
Hi everyone,
as most of you know, even after unlocking the bootloader there are a few more requirements before you can modify the system partition, i.e. install SuperSU, xposed etc.
- Android is now using dm-verity to verfy the integrity of the system partition. Until you switch it off your phone won't boot after modifying /system
- SONY RIC is blocking the write access to the system partition
The good news is, that it is not required to recompile the kernel. It is sufficent to modify the init scripts inside the init ram disk. So you can just stick to the stock kernel.
I created a package which precisely does this job for you. Just run it from TRWP after installing a new Android version
With this you don't have to wait anymore until someone creates the right kernel package for your phone
PS: It leaves a copy of the new boot image in the internal sdcard if you want to save it somewhere. (boot.img) It can be flashed with fastboot if required.
Click to expand...
Click to collapse
Hmm... I don't understand what this zip file do with phone.... Can you explain more primitive for me?!
Is that for recover stock kernel with stock drm keys?! I understand correct?!
zavpasha said:
Hmm... I don't understand what this zip file do with phone.... Can you explain more primitive for me?!
Is that for recover stock kernel with stock drm keys?! I understand correct?!
Click to expand...
Click to collapse
Before you can start to install thing like SuperSU and xposed you have to change the kernel, otherwise your phone won't boot anymore. In the past you had to wait for someone to come up with a compatible kernel for your phone, now this package just converts your existing kernel.
Regarding the DRM please install the package from the DRM restore thread.
Funkmasterchilla said:
I am downloading the whole firmware again from xperifirm. Thank you mate !
Edit: Working great! I'll stick to stock kernel now since Androplus' consumes more battery while asleep !
Edit2: I successfully flashed recoveries in command window from my PC but can't access TWRP at boot though, no LED flashing.
Edit3: Ok that's cuz there's no recovery boot script obviously, my bad. That's above my pay grade, if somebody is kind enough to create a stock. 200 with recoveries it'd be much appreciated PM me if so
Edit!: I flashed monx new stock based kernel
Thank you Tobias !
Click to expand...
Click to collapse
Thanks for the feedback. Future versions of this package will add TRWP as well. I am currently working on it.
tobias.waldvogel said:
Thanks for the feedback. Future versions of this package will add TRWP as well. I am currently working on it.
Click to expand...
Click to collapse
As promised the new package with TWRP is out
tobias.waldvogel said:
As promised the new package with TWRP is out
Click to expand...
Click to collapse
Great work thanks ,
How would I go about disabling the vibration for recovery?
Sent from my E6653 using Tapatalk
Well, the script which checks if recovery should be started is bin/init inside the zip. If you don't like the vibrate then just remove the line and run the package again
Gesendet von meinem E6683 mit Tapatalk
huh, so it is possible to have 2 recoveries at the same time? (and why would anyone want 2 recoveries? )
Three Recoveries are als possible
CWM, Phils Touch & TWRP
Sent from my E6653 @ XDA Portal
Sorry for being noob.
I miss my Oneplus one where things were so easy.
After unlocking BL what do i do with this zip.
Is it going to Root my phone and Install TWRP?
Thanks for help.
I flash the v2 and i got bootloop. 4 time red LED and the phone reboot and all over again. What's the problem?
Hi Tobias,
can you please build a v2 for the z5 compact too?
thx
stiffmeister
FakeSmile said:
I flash the v2 and i got bootloop. 4 time red LED and the phone reboot and all over again. What's the problem?
Click to expand...
Click to collapse
On which model did you use it and with which firmware version?
If you used flashtool before then you can just flash the kernel one more time (i.e. deselect everything else).
stiffmeister75 said:
Hi Tobias,
can you please build a v2 for the z5 compact too?
thx
stiffmeister
Click to expand...
Click to collapse
This should work on Z5 compact with stock kernel as well, without any change.
In case of any issues you can flash the kernel again via flashtool
If it did not work you can pass me the generated boot.img from your interal sdcard for further analysis
hi tobias,
i didn't try the v2, because i thought, that the twrp recovery wouldn't be compatible.
but when you say it's ok, than i'll try it
br
stiffmeister
stiffmeister75 said:
hi tobias,
i didn't try the v2, because i thought, that the twrp recovery wouldn't be compatible.
but when you say it's ok, than i'll try it
br
stiffmeister
Click to expand...
Click to collapse
I flashed zombie kernel without making backup of stock kernel, can you share it with me so I can try this method (I doubt it will work on zombie)
ps : I have .200 fw
tobias.waldvogel said:
On which model did you use it and with which firmware version?
If you used flashtool before then you can just flash the kernel one more time (i.e. deselect everything else).
Click to expand...
Click to collapse
E6653 on .200 firmware

TWRP, System writing, Supersu, Impossible?

I have had my fair share of problems modifying android before but I have never had a phone flat out lie to me and say an operation was successful and actually nothing happened at all.
Have had my nexus 6 for a year or so now. Have had minor issues rooting / modifying marshmallow in the past but I figured out it was all caused by the system partition having basically 0 free space. Made a huge mistake and installed to the latest 7.0 OTA. Wanted to simply enable tethering and edit the thermal config to not shut cores down. Should be as simple as pulling the files, editing them, pushing them back to the phone in twrp with the system partition mounted and thats the end of it right? Wrong.
First of all twrp 3.0.2 refuses to let me touch the system partition without some giant prompt about how its going to make itself stick and offer to root the phone. Simple enough I have seen it in previous versions I say yes as usual except twrp proceedes to immediately spew a bunch of superuser files that do nothing throughout the system partition without asking me if I want root. Dumb but whatever. I mount /system as read write and I go edit and replace my two files like usual (build.prop and thermal config). No matter if I ADB push or use twrps built in file manager it claims the file replacement is successful. Reboot into android and not only have both files not been touched (Verified by adb pull) but the recovery gets overwritten with the factory recovery anyways. (NEVER had issues with twrp sticking on marshmallow. Now after every reboot it gets wiped out)
Second of all if I select yes to twrp mounting system as writable and it does its spewing as I mentioned before then installing SuperSU instantly causes the phone to not boot. Rewrite the boot.img to factory and it boots fine OR Rewrite the clean factory system image and the SuperSU boot works fine. But modifying /system with twrp and then running supersu at the same time is a no go. TWRP is obviously doing something stupid to system that pisses off supersu so undoing twrps mess or uninstalling supersu makes it bootable again.
I dont even want root! Everyone is claiming you need to run "settings put global tether_dun_required 0" as root along with adding the usual "net.tethering.noprovisioning=true" in the build.prop to get native tethering working again! On 6.X only the build.prop edit was needed to get it working.
So long story short. I just want native tethering to work and to tweak my /system/etc/thermal-engine-shamu.conf . Is there anyone here who has done this successfully on nougat? I feel like its all twrps fault but im far too tired and frustrated to try another version tonight.
You must be running an old version of TWRP. Update to the latest, as the latest no longer offers to root your device for you. The version of superuser included was ancient and caused the device to bootloop.
As to TWRP being overwritten Android 7.0 I believe does that on a stock system. If I recall, there is a script that needs to be modified to prevent it.
Strephon Alkhalikoi said:
You must be running an old version of TWRP. Update to the latest, as the latest no longer offers to root your device for you. The version of superuser included was ancient and caused the device to bootloop.
As to TWRP being overwritten Android 7.0 I believe does that on a stock system. If I recall, there is a script that needs to be modified to prevent it.
Click to expand...
Click to collapse
It's stated in the op he's using twrp 3.0.2.
Didgeridoohan said:
It's stated in the op he's using twrp 3.0.2.
Click to expand...
Click to collapse
I misread his post then. I wonder if perhaps he is running TWRP via fastboot instead of installing it.
Flashing recovery using "fastboot flash recovery XXX.img"

Categories

Resources