Develop Bugs

[ThinkTank] Obtaining Perma-Root Discussion

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
In order to keep the Root Progress thread as clean as possible, I took Kenny's advice and created a new thread. So to bring others up to speed, the Galaxy Note 4 variants from AT&T and Verizon have a root, but it's only temporary and resets after a reboot. Also system write is inconsistent.
This thread is for people to share and discuss their ideas and theories of how to make our temp root into a permanent root. Don't be afraid to share or ask any questions you may have because this is the place for them here. Now let's get brainstorming!​

Continuous "Custom padlock" on bootup
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and changing some file permissions and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress, but now pressing the power button brings up the power menu like normal. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?

CJ74753 said:
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
Click to expand...
Click to collapse
Anything is worth mentioning. It's interesting. I've just got my Note 4 warranty replacement yesterday so I'm timid to tinkering with it just yet. On my previous Note 4 I wiped out the EFS while playing in one of those "secret menus' LoL.
My thoughts on how-to obtain permanent root: We'll obviously make use of the temp root from KingRoot, then my idea (if feasible/logical) is to find the flag/eFuse and modify the result or expected result to keep it from reverting back. Now if it's dependent on an eFuse it may not be feasible if it's blown from the factory to lock the bootloader, but if it's like Dan Rosenbergs @djrbliss findings then the eFuse may be blown to unlock the bootloader. It's been a while since I read his findings so I may not be 100% accurate but it makes more sense the first method from a security point-of-view.
Now this was all before dmverity was introduced into KitKat 4.4.4 I believe, so things probably have changed for the worse in our case. I wonder where the weakest link is? I say this because obviously Qualcomm is great at securing their high-level chain of commands lately, but with the Droid Turbo gaining root(same SoC) then I have to believe that a kernel exploit is possible permanently and our road block is Sammy's software. Now with that being said, how tough can their software really be if their flagship S6 (Exynos) was just rooted? BTW good job @idler1984 on that! So you see where I'm going with this right? There's got to be a hole somewhere in Sammy's software after the bootloader, I just don't have a full overview of the boot process as far as where the Qualcomm bootloader hands off to kernel, then to Samsung's KNOX or activation lock etc etc...
Speaking of KNOX (Just rambling here) but has anyone who has used KingRoot ensured that they have turned KNOX and Activation Lock off? That would be funny is that's all it took to retain root

CJ74753 said:
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and changing some file permissions and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress, but now pressing the power button brings up the power menu like normal. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
Click to expand...
Click to collapse
Don't read too much into the custom message you can trip that a variety of ways even before now.

dagolith said:
Don't read too much into the custom message you can trip that a variety of ways even before now.
Click to expand...
Click to collapse
Well my main point here is that I edited the Factory Mode flag to enabled and was able to force the system to keep it set by editing the file permissions. While this don't work with all the files/folders this might be something to look at. I only wish I understood the file system more so I knew if we could possibly keep the system from restoring apps and removing root.

Here is a message I sent Droid.Ninja az I did not want to clog up the other thread with stupid ideas. But, that has been taken care of by others and their talking about off topic stuff. Any way here is a partial quote of what I sent him a few days ago. I hope that there is something useful here.
Jaytronics said:
Kingroot obtains Root. Be it temporary but Root non the less. Now, from my understanding, the device are trying to install the su binary while booted? Now, I know that and this may not matter. But after Kingroot has done its thing, SuperSU can not be utilized. But, what I have found is, that if hitting the SuperSU icon during Kingroot process. It, the SuperSU app has the ability to be activated. Now, when trying to install it's SU binary. It fails. Is this due to the system not having full R-W-E?
Separate idea. So, Root is temp partly because the RAM gets wiped at boot? That is easy to understand. Would there be a temporary way to energize that location before reboot to keep the Root state? I say this because some apps like Xposed need a reboot to work properly. Now whIle being energized could it be possible to back read the binaries that are trying to write to it from the bootloader as it gives off its authentication key or keys? I know absolutely nothing in regards to this stuff. I am guessing and thinking with pseudo logic. So, please don't think me an idiot. One last thing. I want to learn this stuff. I learn best by doing and experimenting. Could you in form me of the tools that you and other devices are using to try and achieve this? I want to dive head first into this stuff. And no, I don't care if I damage my phone. I will just purchase another one when needed. If need be. I hope in some small way I may have helped out. Last thing, would you know where to get a schematic of the board layout and possibly the pinout of components? Ok, I'm done now. By the way, I am not on the AT&T Note 4. I am a Verizon customer. Wish I was not. But, it is almost unfathomable to give up much unlimited data lines. So, I'm stuck with Evilrizon until they rip this away from me.
Click to expand...
Click to collapse

Jaytronics said:
1. Kingroot obtains Root. Be it temporary but Root non the less. Now, from my understanding, the device are trying to install the su binary while booted? Now, I know that and this may not matter. But after Kingroot has done its thing, SuperSU can not be utilized. But, what I have found is, that if hitting the SuperSU icon during Kingroot process. It, the SuperSU app has the ability to be activated. Now, when trying to install it's SU binary. It fails. Is this due to the system not having full R-W-E?
2. Separate idea. So, Root is temp partly because the RAM gets wiped at boot? That is easy to understand. Would there be a temporary way to energize that location before reboot to keep the Root state? I say this because some apps like Xposed need a reboot to work properly. Now whIle being energized could it be possible to back read the binaries that are trying to write to it from the bootloader as it gives off its authentication key or keys? I know absolutely nothing in regards to this stuff. I am guessing and thinking with pseudo logic. So, please don't think me an idiot. One last thing
3. I want to learn this stuff. I learn best by doing and experimenting. Could you in form me of the tools that you and other devices are using to try and achieve this? I want to dive head first into this stuff. And no, I don't care if I damage my phone. I will just purchase another one when needed. If need be. I hope in some small way I may have helped out. Last thing, would you know where to get a schematic of the board layout and possibly the pinout of components? Ok, I'm done now. By the way, I am not on the AT&T Note 4. I am a Verizon customer. Wish I was not. But, it is almost unfathomable to give up much unlimited data lines. So, I'm stuck with Evilrizon until they rip this away from me..
Click to expand...
Click to collapse
1. I've not used King Root yet as I'm on Lollipop so I can't comment on that issue, maybe someone else can add their experience.
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
3. Learn ADB in and out. One of the best Tools you could use. Give up on the unlimited data, it's overrated :good:

ZPaul2Fresh8 said:
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
Click to expand...
Click to collapse
From what I understand we never get to touch the actual file system of the system. This explains the bootup process of Android http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html So upon bootup it copies the system data into RAM. Some how there must be a way to edit this and force the memory to write to the actual partition like how an update would have to do. This is why I was curious about my editing the /efs and making the changes stick by changing the file permissions.

ZPaul2Fresh8 said:
1. I've not used King Root yet as I'm on Lollipop so I can't comment on that issue, maybe someone else can add their experience.
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
3. Learn ADB in and out. One of the best Tools you could use. Give up on the unlimited data, it's overrated :good:
Click to expand...
Click to collapse
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).

Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V

Jaytronics said:
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Click to expand...
Click to collapse
I can guarentee you 100% you won't get they keys there is a reason the bootloader has not been crackdx since the note 2 these are not something that can be so easily obtained
Sent From The EDGE

Question. I am still on lolipop so i haven't tried but seeing as android is basically linux. When we obtain root even though its temp can we or has anyone tried mounting all the partitions in /dev to other location to see whats what and whats editable? I would think as root you could just mount and edit the system partition. Assuming you can find which partition is actually the system part.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app

cstayton said:
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Click to expand...
Click to collapse
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?

delete this if it does help with anything but i was listening to an podcast and they were talking about root and they used an camera app to help install su apk like i said just remember hearing something about it
keep up the good work guys!

CJ74753 said:
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
Click to expand...
Click to collapse
my guess (just speculation at this point) is that the only partition that is :Handled" by the initramfs methods (if that truly is the case) is the system partition (I believe it is mmcblkp026 not sure tho) this would likely make sense due to the fact that if the /EFS partition was also hadled then making changes thru "Secret codes" would also be replaced on reboot meaning that if you borked your IMIE all it would take to fix it is a reboot and from experience we know this is not the case.

Jaytronics said:
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Click to expand...
Click to collapse
Your theory is sound and does (to some extent bare a little further research):
Now to explain what i mean by further research: I have been developing ROMS since the early days of Windows mobile (long before android or iPhones) the original process of packaging and pushing a "ROM" to the mobile device involved several binary edits as you had to move your custom ROM into the exact location within the install package, part of the other issue is that your ROM had to be the EXACT same number of bytes as the OEM thus preventing you from adding to stock unless you removed the exact same number of bytes from your build.
Now as far as the theory being sound here is my explanation for that:
IF (and it's a big IF) we were to compare for instance the BL from a Tmobile note4 to that of ours and determine exactly (and I mean EXACTLY) where the binary portion was that contained the "Keys" and that portion was EXACTLY the same byte size then "In Theory" we could insert the "Keys" from our BL into the Tmobile BL and flash it on our device which since the keys would be correct would not balk at doing so.
Now for the explanation as to why this wont work:
In order to insert our keys into the Tmo BL they litteraly would have to be byte for byte identical or every single byte in the entire BL would be offset and this would in turn cause the flash to fail. And in the event it didn't fail the BL memory space would be offset by the exact same number of bytes and would likely brick your device.

cstayton said:
my guess (just speculation at this point) is that the only partition that is :Handled" by the initramfs methods (if that truly is the case) is the system partition (I believe it is mmcblkp026 not sure tho) this would likely make sense due to the fact that if the /EFS partition was also hadled then making changes thru "Secret codes" would also be replaced on reboot meaning that if you borked your IMIE all it would take to fix it is a reboot and from experience we know this is not the case.
Click to expand...
Click to collapse
The strange thing is if you edit /efs/FactoryApp with permission 0775,which is default, pressing the power button causes the phone to completely shut off, no power menu is shown. Changing it to 0644 yields a working power menu, but selecting any of the files to edit shows each file is blank. But I don't understand the fs enough to know a lot so I was just throwing that piece of information out there.

CJ74753 said:
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
Click to expand...
Click to collapse
cstayton said:
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Click to expand...
Click to collapse
I'm on 4.4.4
I froze all the bloat after the very first boot. Later, after successfully running kingroot, i used root explorer to go in and delete the apks and their associated odex files - both in system/app and system/priv-app. After a reboot, it was all there again.
Running Adaway to put a new hosts file in system/etc also restored the original hosts file after reboot. I was hoping files in system/etc would be more modifiable, but apparently not as Dr. Ketans sound mod apks that modify mixer_paths.xml also reverts.
The only thing that has worked for me is Dr. Ketan's sdcard fix, that allows to write to sdcard in kitkat. That is the only item that has stuck for me of the things I have tried.

jeepers007 said:
I'm on 4.4.4
I froze all the bloat after the very first boot. Later, after successfully running kingroot, i used root explorer to go in and delete the apks and their associated odex files - both in system/app and system/priv-app. After a reboot, it was all there again.
Running Adaway to put a new hosts file in system/etc also restored the original hosts file after reboot. I was hoping files in system/etc would be more modifiable, but apparently not as Dr. Ketans sound mod apks that modify mixer_paths.xml also reverts.
The only thing that has worked for me is Dr. Ketan's sdcard fix, that allows to write to sdcard in kitkat. That is the only item that has stuck for me of the things I have tried.
Click to expand...
Click to collapse
this would definetly point to the initramfs scenario meaning in order for root to "Stick" we would need modifications to kingsroot or whatever perm root method is used to write directly to the mmcblkxx partition rather than the /system folder (which is nothing more than volatile RAM space.)

Same case for me, any changes made were reverted on reboot. I used King to temp root, removed all traces of knox, then actually attempted to convert and install SuperSu but it would not install. Just said that the install failed and to try again.

[FIX] FED-Patcher v7 (ForceEncrypt Disable Patcher)

Hello everybody,
I created a tool for the nexus 9 that gets rid of the ForceEncrypt flag in a generic way (meaning it should work no matter what rom you are on). It does that by patching the currently installed boot.img.
Background
The Android CDD (Compatibility Definition Document) suggests that all devices SHOULD enable full disk-encryption (FDE) by default. Even though I support every step towards more security I have to criticize this approach. FDE comes at a price. Encryption takes time because some component has to de- and encrypt the stuff on the disk at some point and in the case of the nexus 9 (aka flounder) it's the CPU's task. Even though the nexus 9's CPU has 2 pretty fast cores you can still easily feel the difference between FDE in the on- or off-state. The I/O is faster and boot-times take only half as long. (I did not do any measurements)
There is an ongoing discussion about this topic in cyanogenmod's gerrit. Although it's a fun read it is pretty clear that this exchange of views is not going anywhere near a useful outcome.
Because performance is important to me and my tablet does not need the extra security I created the FED-Patcher (ForceEncrypt Disable Patcher)
How does it work?
FED-Patcher is a simple flashable ZIP that is supposed to be run in a recovery that has busybox integrated (like TWRP or CWM). This is what it does:
Checks if your device is compatible
Dumps the currently installed boot.img.
Unpacks the dump of your currently installed boot.img. The unpacking process is done via a self-compiled, statically linked version of unmkbootimg.
It patches the filesystem tables which include the force-encrypt flags. This process will change "forceencrypt" to "encryptable".
Then it patches the filesystem tables to not use dm-verity. This is done by removing the "verify" mount-parameter.
Creates a new boot.img. The unpacking process is done via a self-compiled, statically linked version of mkbootimg.
Flashes the modified boot.img
Supported devices
HTC Nexus 9 WiFi (flounder)
HTC Nexus 9 LTE (flounder_lte)
Motorola Nexus 6 (shamu)
Version History
v1 - Initial version with HTC Nexus 9 WiFi (flounder) support
v2 - Added Motorola Nexus 6 (shamu) support
v3 - Added support for HTC Nexus 9 LTE (flounder_lte)
v4 - Added support for signed boot-images
v5 - Changed error handling to compensate for missing fstab files. Some roms seem not to ship with the complete set of boot-files from AOSP.
v6 - FED-Patcher will enforce the same structure for the patched boot.img that the original boot.img had. Additionally, the kernel commandline will also be taken over. This should fix pretty much every case where devices would not boot after patching.
v7 - FED-Patcher will now disable dm-verity in fstab to get rid of the red error sign on marshmallow roms.
What do I need to make this work?
A supported device (Your nexus 9)
An unlocked bootloader
An already installed ROM with forceencrypt flag. (like cyanogenmod CM12.1)
A recovery that includes busybox (TWRP, CWM)
How do I use it?
Make a thorough, conservative backup of your data if there is any on your device
Go into your recovery (TWRP, CWM)
Flash fed_patcher-signed.zip
If your device is already encrypted (You booted your ROM at least once) you need to do a full wipe to get rid of the encryption. This full wipe will clear all your data on your data-partition (where your apps as well as their settings are stored) as well as on your internal storage so please, do a backup before. If you don't do a backup and want to restore your data... well... Call obama.
How do I know if it worked?
Go into your "Settings"-App. In "Security", if it offers you to encrypt your device it is unencrypted. If it says something like "Device is encrypted" it indeed is encrypted.
IMPORTANT: If you update your ROM you have to run FED-Patcher again because ROM-updates also update the boot-partition which effectively removes my patch. So, if you are on CM12.1 for example and you used my patch and do an update to a newer nightly you have to run FED-Patcher again. If you don't do so Android will encrypt your device at the first boot.
Is it dangerous?
Well, I implemented tons of checks that prevent pretty much anything bad from happening. But, of course, we're dealing with the boot-partition here. Even though I tested FED-Patcher quite a lot there is still room for crap hitting the fan.
Screenshot
Scroll down to the attached thumbnails.
Credits
* pbatard for making (un)mkbootimg (dunno if he is on xda)
* @rovo89 for his xposed framework - I used some of his ideas by reading the source of his xposed installer flashable ZIP for FED-Patcher.

Thanks for creating this! In theory, would this work for the Nexus 6 as well? It would seem like it's a similar process.

itlnstln said:
Thanks for creating this! In theory, would this work for the Nexus 6 as well? It would seem like it's a similar process.
Click to expand...
Click to collapse
Hey there,
yes, it would probably work because the process itself is pretty generic. The only real difference between devices is the device-path for the boot-partition as well as the path(s) for the fstab-file(s) inside the boot.img. Nothing that cannot be done - but I don't have a device for testing. If you feel adventurous I can do a nexus6 (shamu) version for you for testing. I will double check so it should not eff up your device .
EDIT: Not to forget, the nexus 9 is a 64bit device. mkbootimg as well as unmkbootimg are compiled for 64bit. I have to rebuild those two programs for 32bit to make them work for 32bit devices.

If you have time for a N6 build, that would be great. If not, it's not a big deal since there seems to be more support for that device.

itlnstln said:
If you have time for a N6 build, that would be great. If not, it's not a big deal since there seems to be more support for that device.
Click to expand...
Click to collapse
Well, it's pretty much done. Do you want to test a version that does not actually flash anything but do everything else - just to see if it works correctly?

Absolutely!

itlnstln said:
Absolutely!
Click to expand...
Click to collapse
Alright, here you go!
If no error occurs there will be the already modified boot.img file in your temp-directory of your nexus 6. You can send me this file to be completely sure that everything went according to plan. Here is the adb-command:
Code:
adb pull /tmp/fed_patcher/boot-new.img
If all goes well I will upload the new version with nexus 6 (shamu) support tomorrow.
Good night!

gladiac said:
Alright, here you go!
If no error occurs there will be the already modified boot.img file in your temp-directory of your nexus 6. You can send me this file to be completely sure that everything went according to plan. Here is the adb-command:
Code:
adb pull /tmp/fed_patcher/boot-new.img
If all goes well I will upload the new version with nexus 6 (shamu) support tomorrow.
Good night!
Click to expand...
Click to collapse
Thanks! It seemed to work OK. Here's the boot image.

itlnstln said:
Thanks! It seemed to work OK. Here's the boot image.
Click to expand...
Click to collapse
Thanks for your help! I just updated the flashable ZIP in the first post. Enjoy

gladiac said:
Thanks for your help! I just updated the flashable ZIP in the first post. Enjoy
Click to expand...
Click to collapse
You're the best! Thanks!

I noticed in op it says "4 pretty fast cores". This puppy only has 2 cores. Just throwing it out there for readers that don't know. I'm sure it was just a minor oversight.
Sent from my Nexus 9

madbat99 said:
I noticed in op it says "4 pretty fast cores". This puppy only has 2 cores. Just throwing it out there for readers that don't know. I'm sure it was just a minor oversight.
Sent from my Nexus 9
Click to expand...
Click to collapse
Hi,
you are right, thanks. I just fixed the text in the op.

Hey everybody,
I will enable support for the Nexus 9 LTE (flounder_lte) this afternoon in FED-Pather v3. If you want other devices to be supported please tell me. Is there a list of android devices that have forced encryption?

So this works great, leaving device unencrypted. But anyone having issues with apps crashing? Most especially Google Play Services?

femmyade2001 said:
So this works great, leaving device unencrypted. But anyone having issues with apps crashing? Most especially Google Play Services?
Click to expand...
Click to collapse
This problem is new to me. My patch only modifies the boot-image so that it does not enforce encryption. It is merely a flag in fstab that gets changed and should not have anything to do with crashing apps. Anyway, do you have a logcat?

Hey everybody,
v3 is here with HTC Nexus 9 LTE (flounder_lte) support!
Enjoy

I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.

itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Hi, sorry to hear that. I will have a look into the boot.img that gets shipped with LMY48M. Not sure what is going on here.

itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Alright - unmkbootimg fails because the boot.img that google ships has 256 Bytes of extra data (it is probably signed or something) at the beginning. If you strip that off it works correctly:
Code:
dd if=boot.img of=boot-stripped.img bs=256 skip=1
Well, this was unexpected. But nothing that cannot be dealt with. I will make my flashable ZIP search for the offset of the boot.img-signature inside the dumped boot.img and strip of the preceding data. The rest of the process should work as usual.

itlnstln said:
I'm getting an error with my N9 (WiFi). When I try flashing in TWRP, it throws this error:
! Unpacking failed
=> unmkbootimg return value: 0
E: Error executing updater binary in zip...
All I did was go into fastboot, flash the updated image for LMY48M, then go into TWRP to flash the fix. I even went back into fastboot to try re-flashing the boot.img.
Click to expand...
Click to collapse
Hi @itlnstln,
I just made a new version which should do the trick. I tested the new functionality to the best of my knowledge. If the script fails for some reason it wont flash anything - so the probability for actual damage is very low. Do you feel adventurous xD?
Please tell me if it worked for you or not.

[Root Question] How to I Install Xposed on Rooted Amazon Fire TV 2? (Guide Please)

How to I Install Xposed on Rooted Amazon Fire TV 2? (Guide Please)
Do I download XposedInstaller_3.0_alpha4.apk? and xposed-v78-sdk21-arm64.zip?
Please Help
Could I Use Flashfire?

You can't install xposed since there is no custom recovery

Tried with Flashfire where no custom recovery is needed ? what version of xposed should i try?

No Luck with Flashfire and xposed v78-sdk22-arm 64. Going to have to wait for a fix

yeah I've had no luck, just have to wait I guess

ians325 said:
No Luck with Flashfire and xposed v78-sdk22-arm 64. Going to have to wait for a fix
Click to expand...
Click to collapse
Did you encounter boot loop or soft-brick when you attempted this?

z_thompsonpa said:
Did you encounter boot loop or soft-brick when you attempted this?
Click to expand...
Click to collapse
No

ians325 said:
No
Click to expand...
Click to collapse
Thanks! You prompted me to give this a shot after confirming that it wouldn't do any serious damage. I found some things out in the process that explain why this isn't working as of yet.
The Xposed zip you mentioned requires the following Linux GNU tools (or equivalent):
cut
find
head
sed
I suspect this is why it is failing, because I was able to backup my system partition and restore my backed-up system partition through FlashFire. (more on this later)
Sooo.. I thought why not go all the way and try to install BusyBox first? ..since this would fix the missing commands
Much to my surprise the Busybox install actually worked and I had the whole suite of linux commands at my disposal!!!
Things went south pretty quick, though, when I realized that SELinux was blocking my ability to run the following command:
I couldn't run this command:
Code:
mount -o remount rw /system
So, this would prevent a further attempt at installing Xposed through Flashfire, because it would have to mount the system partition as rw in order to modify the files and add the Xposed framework.
I ended up restoring my system partition after this fiasco using Flashfire. It re-enabled my ability to remount /system as rw and SELinux has seemed to calm down in the logs.
In conclusion:
Xposed requires Busybox
[*]SELinux enforces more policies when Busybox is installed
[*]Setting SELinux to Permissive has no effect
EDIT: **Details in my next post**

z_thompsonpa said:
Thanks! You prompted me to give this a shot after confirming that it wouldn't do any serious damage. I found some things out in the process that explain why this isn't working as of yet.
The Xposed zip you mentioned requires the following Linux GNU tools (or equivalent):
cut
find
head
sed
I suspect this is why it is failing, because I was able to backup my system partition and restore my backed-up system partition through FlashFire. (more on this later)
Sooo.. I thought why not go all the way and try to install BusyBox first? ..since this would fix the missing commands
Much to my surprise the Busybox install actually worked and I had the whole suite of linux commands at my disposal!!!
Things went south pretty quick, though, when I realized that SELinux was blocking my ability to run the following command:
Code:
mount -o remount rw /system
So, this would prevent a further attempt at installing Xposed through Flashfire, because it would have to mount the system partition as rw in order to modify the files and add the Xposed framework.
I ended up restoring my system partition after this fiasco using Flashfire. It re-enabled my ability to remount /system as rw and SELinux has seemed to calm down in the logs.
In conclusion:
Xposed requires Busybox
SELinux enforces more policies when Busybox is installed
Setting SELinux to Permissive has no effect
Click to expand...
Click to collapse
Nice work, have you seen this tidbit on BusyBox Github for SELinux?
https://github.com/ukanth/afwall/wiki/BusyBox#difference-between-selinux-and-non-selinux-busybox
There's also some decent results on Google that may offer some clues... https://www.google.com/search?q=SELinux+mount+system+as+rw+android&ie=utf-8&oe=utf-8

fldash said:
Nice work, have you seen this tidbit on BusyBox Github for SELinux?
https://github.com/ukanth/afwall/wiki/BusyBox#difference-between-selinux-and-non-selinux-busybox
There's also some decent results on Google that may offer some clues... https://www.google.com/search?q=SELinux+mount+system+as+rw+android&ie=utf-8&oe=utf-8
Click to expand...
Click to collapse
Thanks for helping out. I jumped the gun on blaming SELinux. I'll go back and edit my previous post.
BusyBox, as far as I can tell works great!
(It will probably require more testing, but for the time being I am not having any issues.)
I figured out what was causing the problem with the inability to mount /system as rw. It was actually caused by attempting to flash Xposed, I believe. I tried it all again tonight and stopped this time after installing BusyBox and before flashing Xposed using Flashfire. I was still able to mount /system properly with functional GNU utils. I hadn't tested this before at this this stage.
I couldn't remount because of "orphaned inodes" after attempting to flash Xposed. Pretty sure this means its corrupting the partition, but yet its still mountable as read-only.
I restored my /system again to get everything back to normal and just installed BusyBox this time. So far so good...
I want to go back and try to flash Xposed again, and this time look in the logs folder. I think the addition of the BusyBox binaries are causing the installer script to error somewhere else during execution causing the partition corruption. Who knows.. there may be a workaround.

keep up the good work

z_thompsonpa said:
Thanks for helping out. I jumped the gun on blaming SELinux. I'll go back and edit my previous post.
BusyBox, as far as I can tell works great!
(It will probably require more testing, but for the time being I am not having any issues.)
I figured out what was causing the problem with the inability to mount /system as rw. It was actually caused by attempting to flash Xposed, I believe. I tried it all again tonight and stopped this time after installing BusyBox and before flashing Xposed using Flashfire. I was still able to mount /system properly with functional GNU utils. I hadn't tested this before at this this stage.
I couldn't remount because of "orphaned inodes" after attempting to flash Xposed. Pretty sure this means its corrupting the partition, but yet its still mountable as read-only.
I restored my /system again to get everything back to normal and just installed BusyBox this time. So far so good...
I want to go back and try to flash Xposed again, and this time look in the logs folder. I think the addition of the BusyBox binaries are causing the installer script to error somewhere else during execution causing the partition corruption. Who knows.. there may be a workaround.
Click to expand...
Click to collapse
How are you restoring your system partition? Using that diff patcher (for root) with a USB A-A cable?

fldash said:
How are you restoring your system partition? Using that diff patcher (for root) with a USB A-A cable?
Click to expand...
Click to collapse
I haven't had to break out the USB A-A cable yet... thankfully (except for root of course).
I used Flashfire to backup my /system partition as RAW backup before I started all of this experimentation. I have just been restoring back to this known good state using Flashfire after each time I corrupt the system partition.
I intended on trying this method, and if it didn't work to fall back to the method mentioned in the root thread. I checked the logs last night and Flashfire seems to be succeeding at this task, at least.
Right now, I am picking through the Xposed installer script source and using the Flashfire logs to debug why it is failing. It appears to be a permissions issue, but a lot of the stdout/stderr is suppressed so its hard to tell exactly where. When I get home today, I am going to try to modify the installer script to produce more output so I can debug the issue further. If I cant figure it out, I'll post my findings either way.

I've fixed a few bugs in the flash script already, but it always errors on overwriting:
Code:
/system/lib/libart.so
It's throwing some error about read-only filesystem. (I'll post exact error later)
I've thrown in some checks to see if the /system mount is unmounting or something odd like that, but that's not it.
I've got a few guesses as to why, but I am not going to mention them until I have more solid evidence.
Any advice would help as well... I just wanted to post the update I promised.

z_thompsonpa said:
Thanks for helping out. I jumped the gun on blaming SELinux. I'll go back and edit my previous post.
BusyBox, as far as I can tell works great!
(It will probably require more testing, but for the time being I am not having any issues.)
I figured out what was causing the problem with the inability to mount /system as rw. It was actually caused by attempting to flash Xposed, I believe. I tried it all again tonight and stopped this time after installing BusyBox and before flashing Xposed using Flashfire. I was still able to mount /system properly with functional GNU utils. I hadn't tested this before at this this stage.
I couldn't remount because of "orphaned inodes" after attempting to flash Xposed. Pretty sure this means its corrupting the partition, but yet its still mountable as read-only.
I restored my /system again to get everything back to normal and just installed BusyBox this time. So far so good...
I want to go back and try to flash Xposed again, and this time look in the logs folder. I think the addition of the BusyBox binaries are causing the installer script to error somewhere else during execution causing the partition corruption. Who knows.. there may be a workaround.
Click to expand...
Click to collapse
z_thompsonpa said:
I've fixed a few bugs in the flash script already, but it always errors on overwriting:
Code:
/system/lib/libart.so
It's throwing some error about read-only filesystem. (I'll post exact error later)
I've thrown in some checks to see if the /system mount is unmounting or something odd like that, but that's not it.
I've got a few guesses as to why, but I am not going to mention them until I have more solid evidence.
Any advice would help as well... I just wanted to post the update I promised.
Click to expand...
Click to collapse
I think we should go another method. Use the tools in the root thread to just create an image with Xposed/root and just do a DIFF.

fldash said:
I think we should go another method. Use the tools in the root thread to just create an image with Xposed/root and just do a DIFF.
Click to expand...
Click to collapse
I think so... I am pretty sure its a dead end. I also tested using adb to write the files and it failed on /system/lib/libart.so, as well. It's, I believe, because the object is loaded in memory?? don't quote me on that... but loading through preloader, I think, would avoid this limitation as ART is not running.

So can anyone in here tell me if its possible to have xposed on fire tv 2 5.0.5 thats rooted and now has twrp recovery on ? I have tried to flash the xposed zip in recovery but when i reboot its stuck at amazon logo. Went back into recovery and flashed rbox's pre rooted 5.0.5 and booted normally. Id like to have (im sure many others would also) xposed and playstore, ive searched the forums but because rbox method is new there is no information on this subject now.

sconnyuk said:
So can anyone in here tell me if its possible to have xposed on fire tv 2 5.0.5 thats rooted and now has twrp recovery on ? I have tried to flash the xposed zip in recovery but when i reboot its stuck at amazon logo. Went back into recovery and flashed rbox's pre rooted 5.0.5 and booted normally. Id like to have (im sure many others would also) xposed and playstore, ive searched the forums but because rbox method is new there is no information on this subject now.
Click to expand...
Click to collapse
Use this method, I've slightly modified the text from another post & added it into a text file for you, this works a 100% but as usual I take no responsibility if you do any thing wrong & brick the Fire Tv2.
Enjoy & press that thanks button If this helped you

Thanks for this. I will try it shortly and report back if it works for me. I have stumbled upon another thread that the guys seem to be working on playstore issues, http://forum.xda-developers.com/fire-tv/help/q-guide-to-getting-google-play-rbox-t3310974

Made a guide here if anyone wants to install
http://forum.xda-developers.com/fire-tv/general/installing-xposed-fire-tv-2-guide-t3314142

Systemless root, Android Pay, unroot

So the only reason I have to root is to use AdAway. I use Android Pay often as it's convenient. Last I knew, Google had server-side blocked systemless root.
However, if I install systemless root. Install AdAway hosts. Unroot (probably just flash a stock kernel?). This should allow Android Pay to still work?

MattBooth said:
However, if I install systemless root. Install AdAway hosts. Unroot (probably just flash a stock kernel?). This should allow Android Pay to still work?
Click to expand...
Click to collapse
I don't follow AdAway installation that closely, but Nougat introduced forward error correction so any changes to the hosts file will get auto corrected back to original contents unless you disable dm-verity (either manually, installing SuperSU, or modified boot.img)
You could install AdAway systemless, but I think that install option piggybacks on stuff SuperSU creates for its set up.
I might have some of this stuff about AdAway installs incorrect, but the part about changes to the system (and vendor) partitions getting auto error corrected back to original contents I am sure of.
There is a thread about getting tethering working that might provide relevant information on getting root and AdAway working. Changing build.prop and getting the changes to stick is pretty much the same issue as getting changes to hosts to stick.
My guess is you don't want to get rid of SuperSU completely as that would re-enable dm-verity and thus turn on forward error correction. You can probably get rid of some SU binaries that Android Pay security check is looking for but leave the infrastructure SuperSU put in place.

There's an option to symlink the hosts file to AdAways private storage within the /data/data/ folder, but perhaps dm-verity would pick that up as well :/

MattBooth said:
There's an option to symlink the hosts file to AdAways private storage within the /data/data/ folder, but perhaps dm-verity would pick that up as well :/
Click to expand...
Click to collapse
It wouldn't, but I believe when I looked at that script, it piggybacked on some init scripts that the SuperSU install set up, which is why I suggested you might be able to remove the SU binaries but leave the SU infrastructure in place. I didn't look that closely, so I could be mistaken.

Question Read Only Access to System Files after Root

here are some commands I have tried after root following @sd_shadow 's guide
[email protected] ~ $ adb remount
/system/bin/sh: remount: inaccessible or not found
caprip:/ # mount -o rw,remount /system
mount: '/system' not in /proc/mounts
caprip:/ # mount -o rw,remount /
'/dev/block/dm-0' is read-only
caprip:/ # touch file
touch: 'file': Read-only file system

Wanted to post something like this right now since i have the same problem, i think for adb remount to work you need to first run adb root, but that doesnt work unless you modify ro.debuggable=0 to 1 which cannot be done since you cant mount system as rw, i will keep you updated if i find anything tho!
- Apparently you can modify the boot.img to set ro.debuggable=1 but most of the tools i tried dont recognize this phones boot image as valid so i wont really spend more time on this since i think its something way beyond the scope of what i can do. And the only tool that worked outputted a unusable archive, i think this has to do with the source of the device being closed or something related to why we dont have custom roms on this device yet. But dont take my word for it since i just started playing with stuff like this a few hours ago so i can remap the assistant button.
And even if i could modify it i have a hunch it would behave just as using remount from shell.
If anyone who understands this better than me could provide some insight to my rambling it would be great!

The reason for this behaviour is the unified "super" partition. /system is dynamic, i.e. it may change size depending on future updates. /vendor is also a part of the "super" partition, thus is also read only. There is a way to restore rw access but it a) is not guaranteed and b) affects the ability to apply OTA updates.
If you're willing to take the risk, you should be able to find the relevant post on here (XDA, not the G30 section) with some search fu. You will need a Linux machine and the knowledge to use it. The "run on device" unified script does not fully work on the G30 and you need to reconfig the super image on a Linux box.

Chron0s said:
The reason for this behaviour is the unified "super" partition. /system is dynamic, i.e. it may change size depending on future updates. /vendor is also a part of the "super" partition, thus is also read only. There is a way to restore rw access but it a) is not guaranteed and b) affects the ability to apply OTA updates.
If you're willing to take the risk, you should be able to find the relevant post on here (XDA, not the G30 section) with some search fu. You will need a Linux machine and the knowledge to use it. The "run on device" unified script does not fully work on the G30 and you need to reconfig the super image on a Linux box.
Click to expand...
Click to collapse
Can I have some more search terms to find what you are talking about?

I can do better than that but with the usual caveats of bootloops, hard-bricks, kicked kittens, spacetime anomalies and global thermonuclear war:
G30 /system rw
I remain totally immune for blame when this goes wrong. You need a disaster recovery strategy in place before trying this. Read the first post in that thread thoroughly before doing anything.
Make sure you have a copy of the correct stock ROM and at least RSD-lite to recover. Also, revert Magisk patched initrd (boot.img - be sure your stock matches the ROM version or you'll lose the touch screen/RIL) before attempting this method - you can restore it later but the script requires the live ROM on the device to be stock. This is not something Motorola can be blamed for, it's upstream and applies to all devices running with a super partition and dynamic /system and /vendor.
More caveats: You will lose OTA updates. You will still need to boot to fastbootd to access /system. There is still currently no custom recovery for this device. A manual update will put you back to square one, which is why I decided to forget rw on /system and use Magisk to debloat/degoogle as the method employed in the debloater persists across updates.

Chron0s said:
I can do better than that but with the usual caveats of bootloops, hard-bricks, kicked kittens, spacetime anomalies and global thermonuclear war:
G30 /system rw
I remain totally immune for blame when this goes wrong. You need a disaster recovery strategy in place before trying this. Read the first post in that thread thoroughly before doing anything.
Make sure you have a copy of the correct stock ROM and at least RSD-lite to recover. Also, revert Magisk patched initrd (boot.img - be sure your stock matches the ROM version or you'll lose the touch screen/RIL) before attempting this method - you can restore it later but the script requires the live ROM on the device to be stock. This is not something Motorola can be blamed for, it's upstream and applies to all devices running with a super partition and dynamic /system and /vendor.
More caveats: You will lose OTA updates. You will still need to boot to fastbootd to access /system. There is still currently no custom recovery for this device. A manual update will put you back to square one, which is why I decided to forget rw on /system and use Magisk to debloat/degoogle as the method employed in the debloater persists across updates.
Click to expand...
Click to collapse
As long as I still have access to the bootloader I it should be fine? Also others on this device thread don't have this issue, why?

As long as you can boot to fastboot, you should be able to recover. There are, of course, exceptions to this as every G5s plus owner who ever deleted the persist partition without a bit-perfect backup will know only too well.
I haven't seen a single instance of anyone on a dynamic /system device, including the Moto G30, being able to remount /system rw without jumping through hoops like these. Perhaps it is simply because most people know that dynamic /system became A Thing recently. Again, this is on Alphabet, not Lenovo/Motorola.
This is also why this device section is full of "how to root" queries as the traditional method of banging su into /system/sbin and installing a management APK doesn't work with dynamic partitions. The only way to get a working su binary onto the system is via initramfs preloaded with the kernel, which is what Magisk patches and is why Magisk is the only root solution for this device.
If you think I'm typing nonsense, that's fine. Here's the advice, it was free and comes with a guarantee worth exactly what you paid for it.

No, not at all. Thanks for your help, Got error 73 which is where the Linux comes in so I imagine it's probably fine? I'll run the repair script when I get home later.

Error 73 is exactly the error I got, which is indeed why you need the older Linux method of patching the super image.