Develop Bugs

[Q] Advice on updating rooted FTV without going to 51.1.2.0 to

I have a FTV that is rooted and still at 51.1.0.1 I want to upgrade to 51.1.1.0_user_511070220, but don't want to risk going to the latest 51.1.2.0 unrootable version. Can I use adb to copy the upgrade to /cache and upgrade locally with the box disconnected from the internet or does it need to call home when I am doing the local upgrade? I can also block the update sites in the router firewall:
amzdigitaldownloads.edgesuite.net
softwareupdates.amazon.com
once this is done, I can re-run towelroot and disable OTA.
Any advise on the best way to proceed is appreciated.
Thanks in advance for everyone's help!

Yes, do the manual upgrade to the latest rootable firmware. Follow the directions on http://www.aftvnews.com/how-to-manually-upgrade-or-downgrade-the-amazon-fire-tv/ That is the best way to upgrade without jumping through each upgrade.
It will need internet connection, I removed mine before upgrade and it would not let me proceed and get stuck on the network selection pickup. Maybe after you have pushed the upgrade.zip to your cache and send it a recovery reboot command, you can disconnect the internet. I did not, so not sure if that works.
Before you do anything, make sure you have blocked those 2 sites. Re-verify it before you proceed.
Once you upgrade, immediately disable the FTV upgrade package. I would suggest to keep the blocks on those 2 sites even after you disable the FTV auto upgrade.

dbdoshi said:
Yes, do the manual upgrade to the latest rootable firmware. Follow the directions on http://www.aftvnews.com/how-to-manually-upgrade-or-downgrade-the-amazon-fire-tv/ That is the best way to upgrade without jumping through each upgrade.
It will need internet connection, I removed mine before upgrade and it would not let me proceed and get stuck on the network selection pickup. Maybe after you have pushed the upgrade.zip to your cache and send it a recovery reboot command, you can disconnect the internet. I did not, so not sure if that works.
Before you do anything, make sure you have blocked those 2 sites. Re-verify it before you proceed.
Once you upgrade, immediately disable the FTV upgrade package. I would suggest to keep the blocks on those 2 sites even after you disable the FTV auto upgrade.
Click to expand...
Click to collapse
If you have dcp blocked before doing the update, it should remain blocked after the update.

rbox said:
If you have dcp blocked before doing the update, it should remain blocked after the update.
Click to expand...
Click to collapse
Thanks, that is good to know and comforting.

rbox said:
If you have dcp blocked before doing the update, it should remain blocked after the update.
Click to expand...
Click to collapse
You are probably right, I am a novice to this. But, I swear to God, I seem to remember not dcp blocking it on a friend's FTV when I upgraded his to the latest rootable firmware and checking the system on FTV did not generate the error or "Checking now..." message (His was blocked before the OTA upgrade). So, to clarify, the block remains for OTA and manual upgrade both?

dbdoshi said:
You are probably right, I am a novice to this. But, I swear to God, I seem to remember not dcp blocking it on a friend's FTV when I upgraded his to the latest rootable firmware and checking the system on FTV did not generate the error or "Checking now..." message (His was blocked before the OTA upgrade). So, to clarify, the block remains for OTA and manual upgrade both?
Click to expand...
Click to collapse
The block *should* remain. I can't imagine why it wouldn't. But I haven't really done any extensive testing on it. Doing the OTA and doing the manual upgrade are the same. The manual upgrade is manually doing exactly what the OTA does. The OTA downloads the .bin file, and tells recovery to flash it and reboots to recovery. The problem comes if you get an OTA update to the unrootable firmware. The dcp will remain blocked, but you won't be able to gain root anymore.

rbox said:
If you have dcp blocked before doing the update, it should remain blocked after the update.
Click to expand...
Click to collapse
I updated the box to 51.1.1.0_user_511070220 last night. No problems at all. I used this process to update the box:
http://forum.xda-developers.com/showthread.php?t=2796067
I used ftp to binary transfer the update file to /cache/update.zip and I set r/w permissions on this file.
the /cache/recovery folder did not exist (needed in tutorial above) so I created it and did a chmod 777 /cache/recovery
Once the update completed, I re-rooted the box - towelroot, Let it rain button.
I forgot to check if the dcp package was still disabled. I ssh'ed to the box and disabled it just to make sure.
I also had to run busybox to re-install it.
I was using the install-recovery-2.sh trick to mount my usb stick, so I lost this and had to recreate /system/etc/install-recovery-2.sh (set execute permission on it and add the line:
mount -t ext4 /dev/block/sda1 /data/sdext2
install-recovery-2.sh is a non-existent file that is called in the last line of install-recovery.sh. This is executed during the boot process and can be used to execute commands when booting. To take advantage of this, create the install-recovery-2.sh file and add the lines you want executed. you have to set execute permission on the file.
su
mount -o rw,remount /system
create and add commands to /system/etc/install-recovery-2.sh
( I added: mount -t ext4 /dev/block/sda1 /data/sdext2 (where /data/sdext2 is where I want my flash drive to show up)
chmod 755 /system/etc/install-recovery-2.sh
mount -o ro,remount /system
exit

Can this be used to exploit much more interesting commands?
Such as making a backdoor for rooting the unrootable OTA update and even unlocking the bootloader/Custom ROM?
Edit:What about overclocking by permanently modifying the related files to set GPU to minimum 400Mhz and maximum 500Mhz and overclocking the CPUs to a maximum of 1.9Ghz or 2.0Ghz?
If it can be used to overclock,please elaborate on how you can do it?
I posted the directory of the related files in a topic a while back.

retroben said:
Can this be used to exploit much more interesting commands?
Such as making a backdoor for rooting the unrootable OTA update and even unlocking the bootloader/Custom ROM?
Click to expand...
Click to collapse
So that is a good idea, but unfortunately the first thing that happens when you install the OTA is it wipes /system. But once you have root, anything you could put in that script, you could manually run as root, so it can't let you do anything extra.
As for custom roms, the good news is that the OS on the Fire TV is pretty much stock CAF android. The kernel can boot AOSP/CM as is. And using a similar but different script earlier in the boot process, I'm able to get Safestrap working. I currently have Clockwork mod working, but Safestrap uses TWRP and as of yet I have been unable to get TWRP to display anything on the TV. I'm going to try to work on it some more this weekend.

rbox said:
So that is a good idea, but unfortunately the first thing that happens when you install the OTA is it wipes /system. But once you have root, anything you could put in that script, you could manually run as root, so it can't let you do anything extra.
As for custom roms, the good news is that the OS on the Fire TV is pretty much stock CAF android. The kernel can boot AOSP/CM as is. And using a similar but different script earlier in the boot process, I'm able to get Safestrap working. I currently have Clockwork mod working, but Safestrap uses TWRP and as of yet I have been unable to get TWRP to display anything on the TV. I'm going to try to work on it some more this weekend.
Click to expand...
Click to collapse
Rbox,
Sounds very interesting. Keep the good work.

rayosx said:
Rbox,
Sounds very interesting. Keep the good work.
Click to expand...
Click to collapse
So I was finally able to get TWRP booting and displaying (in the correct colors). As you can see, it doesn't fill the screen. The problem is TWRP needs theme files to match the resolution, and it currently has no support for 1080p, although adding support for 1080p isn't the problem. It's figuring out if I should add in dynamic switching support to let it switch between 1080p and 720p. Which is why I need people to fill out the poll I created here.
The other problem with 720p is my TV is 1080p, so I can't really test it. Does anyone know if there is TWRP support for any of the other android based TV devices like OYUA or whatever?

What?
The 720p mode works on 1080p TVs since I used that mode briefly until switching to 1080p for better quality.

retroben said:
What?
The 720p mode works on 1080p TVs since I used that mode briefly until switching to 1080p for better quality.
Click to expand...
Click to collapse
Unfortunately in recovery, if the graphics are 720p then it won't fill the screen at 1080p. Although now that I think about it, I wonder if I could set it up to just scale up from 720 to 1080. That would probably be easiest.

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

Android 7.0 & /etc/hosts

/etc/hosts blacklist entries seem to be ignored with Android 7.0 (e.g. adding 127.0.0.1 amazon.com still allows me to reach amazon.com). Is anyone else experiencing something similar or familiar with any gotchas around Android 7.0 and modifying /system/etc/hosts?
I'm running official Nexus 5X Android 7.0 build number NRD90R. I have an engineering build of android that I boot from as follows to modify my /system/etc/hosts file:
adb reboot-bootloader
fastboot boot my-recovery.img
<mount from phone menu>
adb remount
adb push my-hosts system/etc/hosts
adb shell
chmod 644 system/etc/hosts
exit
<reboot from phone menu>
I've been using this process after every OTA update since Android 6.0, and it's been working. I also noticed that I'm not getting the red warning on boot any more (the one you get after you modify anything on the system partition), just the yellow warning (the one you get from having phone unlocked). Maybe I did something wrong ¯\_(ツ)_/¯ but I could sure use a sanity check.

Could be related to java cache, after a modification to hosts file you should reboot to let the cache reload. Try it.

The OS is not booted when editing hosts since it's being edited from a recovery image with the system mounted into it. The last step is to reboot. I did reboot the phone again for good measure and it's still not working. If it is a cache related thing, it lives through reboot. I suspect it's not though as I was seeing ads in news websites that I do not frequent.
Any other thoughts?

Are you using chrome? Did you disable data saver option in chrome?
Sent from my SHIELD Tablet K1 using Tapatalk

Seems to be related to: http://forum.xda-developers.com/nex...oid-nougat-t3445647/post68737720#post68737720 . Basically the files that one would modify by mounting /system are no longer used, afaict.
When I boot a live image, mount the system partition, and make a modification (i.e. /system/etc/hosts), that change is persisted through a reboot back to the live image and remount. However, it's not loaded by the OS when it boots. Instead both /etc/hosts and /system/etc/hosts are unmodified. Odd, and why is there even anything mounted at /system? I'm not sure if there are multiple system partitions or what's going on. I would love to find some information about Android 7.0 that explains.

crashenx said:
Seems to be related to: http://forum.xda-developers.com/nex...oid-nougat-t3445647/post68737720#post68737720 . Basically the files that one would modify by mounting /system are no longer used, afaict.
When I boot a live image, mount the system partition, and make a modification (i.e. /system/etc/hosts), that change is persisted through a reboot back to the live image and remount. However, it's not loaded by the OS when it boots. Instead both /etc/hosts and /system/etc/hosts are unmodified. Odd, and why is there even anything mounted at /system? I'm not sure if there are multiple system partitions or what's going on. I would love to find some information about Android 7.0 that explains.
Click to expand...
Click to collapse
I responded to your post in the other thread. This is repost.
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.

sfhub said:
I responded to your post in the other thread. This is repost.
Android 7.0 introduced redundant bits for reed solomon forward error correction into the system and vendor partitions and code in the kernel to perform the error correction.
Your changes are being written to emmc but when you boot with 7.0 kernel with dm-verity enabled your changes are being treated as data corruption and on-the-fly error corrected back to original.
You can see your changes if you boot into twrp because it has dm-verity disabled. However if you boot into android with dm-verity enabled it will look like original image again even though your changes are technically still there.
It took me a day to figure out what was really going on because i initially had no idea they added this feature to Android N.
The simple way to disable dm-verity is to install SuperSU, but you can also accomplish the same patching your own kernel, installing pre-patched kernel, installing custom kernel, etc.
Click to expand...
Click to collapse
That's good info and makes total sense. Thanks! Pretty neat actually, just a bummer for me.
Yeah so SuperSU path is not really one I want to pursue. I could learn how to update the dm-verity shas used for verification. That'd probably be the most secure, but it's gonna be a PITA I bet. I imagine I'd need to compile my own image similar to how I made my live image and update a few things. Might have to deal with encryption which is probably an even bigger headache. Also, I bet it would break OTA and have to reflash to update, though that's true now.
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
I really appreciate you pointing us in the right direction.

crashenx said:
I'm really curious what AdAway is doing. Maybe I should pursue reverse engineering that.
Click to expand...
Click to collapse
I don't use adaway but I believe there are 2 ways to install it with Android N. First is to install SuperSU (or otherwise disable dm-verity) and have it update as it always has. 2nd way is systemless where it piggybacks on some init scripts SuperSU has created to mount "over" the existing hosts file. Basically like symlinking but using a mount point on top of the existing file.

sfhub said:
I don't use adaway but I believe there are 2 ways to install it with Android N. First is to install SuperSU (or otherwise disable dm-verity) and have it update as it always has. 2nd way is systemless where it piggybacks on some init scripts SuperSU has created to mount "over" the existing hosts file. Basically like symlinking but using a mount point on top of the existing file.
Click to expand...
Click to collapse
I'll probably try to go the route of updating init scripts to mount over the existing host file but without using SuperSU or AdAway.

Rom Access or advice for TAB S4

My device was fine before Rooting importantly the Bluetooth stack was was also fine. However, after rooting all BT Pairings are lost across reboots etc. Just turning BT off then on again causes the issue making it necessary to delete and re-pair every time the device starts. over the last week i've ran various tests, and concluded the issue lies with either the hardware or the stock image i got from Sammobile.com. Being a noob, during my experimentation i have had to flashback to the stock image on several occasions. Only discovering the Bluetooth issue when putting my work to good use and using the device.
Yesterday i tested the theory. Flashed it to stock, booted to OS and skipped all the config disabled WI-FI and DATA so it couldn't pull updates. Tested Bluetooth and the issue is present. The Bluetooth did work correctly before i started rooting it. This is unlikely a hardware issue so can only assume its an issue in the build i have from Sammobile. If any of you have access to a stock pre-installed rom that works that they could give me access to, so i can do some testing or indeed any advice it would be very much appreciated.
Device = Samsung Galaxy Tab S4 (SM-T835 on EE)
PDA = T835XXU2ARJ3
CSC = T835OXM2ARJ3
Many thanks
Colin

This is known issue once rooted, however it has already been fixed. There is a module that you need to load via Magisk. Search for: libsecure_storage companion for rooted Samsung devices. Load that up and you'll be good to go.

cbb77 said:
This is known issue once rooted, however it has already been fixed. There is a module that you need to load via Magisk. Search for: libsecure_storage companion for rooted Samsung devices. Load that up and you'll be good to go.
Click to expand...
Click to collapse
thanks for the info, i saw a few threads a few days ago about secure storage and did it manually which didn't help with the issue. similarly neither does the module for Majisk . a case of keep looking i guess. any other suggestions will be very much appreciated

Hmm, I would try uninstalling and reinstalling again via Magisk to confirm. I have rebooted multiple times and the bluetooth pairings stick for me. I do have T830 vs. the T835 that you have but I wouldn't think that it should matter. Worth another shot anyway.

cbb77 said:
Hmm, I would try uninstalling and reinstalling again via Magisk to confirm. I have rebooted multiple times and the bluetooth pairings stick for me. I do have T830 vs. the T835 that you have but I wouldn't think that it should matter. Worth another shot anyway.
Click to expand...
Click to collapse
Cheers will give it a go - at this point i have nothing to lose, just taken a fresh backup so nothing ventured nothing gained

its stuck no boot while removing secure_storrage module from majisk
Oddly having tried the suggestion above of removing the majisk module the device no longer boots it gets stuck on the Samsung logo. For some reason the vendor partition is no longer able to mount.. Completed a restore eventually to get it to boot. Disabling the module yields the same result. no vendor partition and no boot. Going back to an earlier backup prior to the module being installed

The plot thickens
Today i'm still trying to find a fix for disappearing Bluetooth devices. Using the Magisc module cases my Tab to stall during boot on the Samsung logo similarly trying to replace the /vendor/lib and /vendor/lib64 binaries manually also causes the system to freeze on the Samsung logo. looking at the binaries and some path file references there in. It would appear as though my tablet is missing some key files or folder so far the following are missing
/data/system/secure_storage/ls_data.db
/dev/.ashem.secure_storage_ashem
/dev/.secure_storage/sd_socket.ro
any of you have any thoughts

c6pea said:
Today i'm still trying to find a fix for disappearing Bluetooth devices. Using the Magisc module cases my Tab to stall during boot on the Samsung logo similarly trying to replace the /vendor/lib and /vendor/lib64 binaries manually also causes the system to freeze on the Samsung logo. looking at the binaries and some path file references there in. It would appear as though my tablet is missing some key files or folder so far the following are missing
/data/system/secure_storage/ls_data.db
/dev/.ashem.secure_storage_ashem
/dev/.secure_storage/sd_socket.ro
any of you have any thoughts
Click to expand...
Click to collapse
You actually only need to replace the libsecure_storage.so libs and set the correct permissions.
Add the following to the build.prop:
ro.securestorage.support=false

Boot failure when LIbs replaced
ashyx said:
You actually only need to replace the libsecure_storage.so libs and set the correct permissions.
Add the following to the build.prop:
ro.securestorage.support=false
Click to expand...
Click to collapse
No matter how i do this, the device failes to boot and gets stuck on the samsung logo.
Install the majsik module through majisk reoot when prompted = device brick
making all the changes manually including the changes to the build.prop in the /vendor partition = device brick on reboot.
Tried Using instructions and librarys from the following post
https://forum.xda-developers.com/sa.../guide-fix-bluetooth-losing-pairings-t3798262
Although, the above post says to replaces the libs in the system folder which serves no purpose but replacing them in the vendor partition causes the device to brick at next boot.
Thanks far the suggestions, Still looking

c6pea said:
No matter how i do this, the device failes to boot and gets stuck on the samsung logo.
Install the majsik module through majisk reoot when prompted = device brick
making all the changes manually including the changes to the build.prop in the /vendor partition = device brick on reboot.
Tried Using instructions and librarys from the following post
https://forum.xda-developers.com/sa.../guide-fix-bluetooth-losing-pairings-t3798262
Although, the above post says to replaces the libs in the system folder which serves no purpose but replacing them in the vendor partition causes the device to brick at next boot.
Thanks far the suggestions, Still looking
Click to expand...
Click to collapse
Is this happening with only the storage libs or does it happen if you make any other changes to vendor?

ashyx said:
Is this happening with only the storage libs or does it happen if you make any other changes to vendor?
Click to expand...
Click to collapse
Thanks for the assist
It occurs only when the Libs are changed.
Originally using the majsic module to install the libs it couldn't overwrite the files as they are in use. modifying the build.prop seemed to resolve that but as soon as those libs are change either manually through terminal or via the installer i end up with a soft brick LOL
its Bugging me!!!

Interestingly
Once the device hangs.
Simply restoring the vendor partition doesn't fix the boot issue.
In order to get the device to boot I have to restore /data (you don't need to restore /vendor just /data)
oddly restoring the /data partition restores the 2 library files in /vendor to their respective originals

Majisk zip extraction issue
so I have resolved the Bluetooth issue, Rather having majisk install the module i just downloaded it and extracted the contents and discovered that upon zip extraction the contents of each file were appended to themselves. see screenshot "confused.jpg" of the readme.md - so in relation to the library files, the files being installed were double in size hence corrupt.
ie /vendor/lib/secure_storage.so should =308kb the file being insatalled in my /vendor/lib partition was 616kb the 64 bit library was also double the size it should have been.
infarct all the files within the Zip had the same issue.
so i extracted the Zip contents on my pc and transferred the library files via usb. made the relevant changes to build.prop and stopped the secure_storage deamon. Machine now boots and Bluetooth pairings are retained across reboots.
Small Wins
Any one have a clue why the files would double up on content??????

built in zip extractor
the issue i have is with the stock zip extraction tool.
extracting the zip file content on the tablet with winzip. the files are as they should be

c6pea said:
the issue i have is with the stock zip extraction tool.
extracting the zip file content on the tablet with winzip. the files are as they should be
Click to expand...
Click to collapse
7zip is the extraction utility you want. Winzip is pants.

ashyx said:
7zip is the extraction utility you want. Winzip is pants.
Click to expand...
Click to collapse
Use winrar on the PC used it for a 15 year haha
only installed winzip to test another extraction tool on the tablet, low and behold the extracted content of the file is as it should be. Unlike the tablets stock zip extractor utility

c6pea said:
Use winrar on the PC used it for a 15 year haha
only installed winzip to test another extraction tool on the tablet, low and behold the extracted content of the file is as it should be. Unlike the tablets stock zip extractor utility
Click to expand...
Click to collapse
Same for winrar, closed source bloated rubbish.
7zip supports practically every format and totally ad free.

Wait until your device is fully rebooted before opening apps [REWARDED]

Hello friends!
I need a lot help.
If I fail to repair the operating system and work as before, I am impetuously interested in recovering at least the data on the /sdcard (internal phone storage) because I HAVE NO BACKUP and I need that data lke the air.
I have a Xiaomi Redmi Note 8 (Ginkgo) with stock ROM MIUI India/Global (11.0.6.0.PCOINXM), TWRP (3.3.1.0) and Magisk (v20.1 or 20.3 - I don't remember exactly).
About two days ago Revolut no longer allowed me to use the application because the phone is rooted. I needed to make an immediate transfer, so I started playing with Magisk because it didn't pass the SafetyNet test. Until then I had installed only Magisk, I updated to the latest version v21.2, I also installed two modules: MagiskHide Props Config (latest version) and Universal SafetyNet Fix v1.1.0. Plus the latest version of TWRP (3.5.0_9-0).
After running "props" in the terminal, I followed the steps (1, f, Xiaomi, 71 ...) and selected my phone from the list I managed to pass the SafetyNet test, but Revolut still did not work.
After that I tried to disguise the Magisk application with another name to hide it (that's how I saw it through some tutorials), but without success because I didn't activate install applications via USB (something like that).
I left the phone for about half an hour, and then the PROBLEMS BEGUN.
For each application I want to launch I receive the following message "wait until your device is fully rebooted before opening apps". I restarted the phone countless times and nothing. I noticed that TWRP does not decrypt user 0 or 999, so I changed TWRP to the previous version, uninstalled Magisk, deleted the modules from /data/adb/modules, upgraded to MIUI v11.0.6.0 and then MIUI v12.0.1.0 - and the problem persists.
I mention that using TWRP File Manager all the content from /data/data and /sdcard is encrypted (files and folders have unintelligible names). The rest of the files are ok.
Although developer mode is enabled, I don't have USB debugging enabled, and the default USB connection is set to charging and as I constantly get the error "wait until your device is fully rebooted before opening apps" I can't change them.
When I open the phone, at the lockscreen, I have a pattern that I successfully insert and the phone opens. The same pattern in TRWP does not decrypt the data.
Given the fact that it accepts the pattern password, I think that if I had a USB connection I would have managed to recover decrypted content from the internal storage space of the phone. Or is the error I receive exactly due to the fact that the applications no longer have access to the content because it is encrypted?
If so how can I recover all the encryption keys to backup them and then how can I try to fix this problem? Or if the keys have been altered, can they still be generated again (if the phone is the same, as well as the IMEI or serial number, etc)?
I understand that if I solve this problem I will either recover my phone as before or at least I can decrypt and access the data and make a backup.
It is very frustrating to see that the necessary information is still there, but I cannot access it.
Because I have access to the system with TWRP, I think I can attach logs.
I hope no one feels offended, but I am so desperate that I am willing to pay a reward.
Please help me!

Here is my video for a better understanding.
https://www.dropbox.com/s/ob235116jpnbj/ginkgo.mp4?dl=0

When I used MagiskHide, it changed my default.prop
Is it possible that the above problem is due to this fact?
How can I copy default.prop (original from wife's phone - same model) from SD card to phone?
Nothing changes with TWRP File Manager copy/paste. Can a script be used to be flashed with TWRP?

Any prop changes that were made with MagiskHide or MagiskHide Props Config did not touch any of your actual prop files. Your default.prop (and any other prop files) are going to be exactly as they were before enabling MagiskHide or changing prop values with MagiskHide Props Config.
Magisk does these things systemlessly, which means it doesn't actually alter the files. This (default.prop) is not your issue... How did you come to the conclusion that Magisk had changed your prop file anyway?
Since you've uninstalled Magisk and the modules, and even updated your OS and the problem still persists it is unlikely that it's directly related to Magisk. I know very little of MIUI though, so I'll leave the rest of the troubleshooting to those that do.

Thanks for the help and for the reply!

Didgeridoohan said:
Any prop changes that were made with MagiskHide or MagiskHide Props Config did not touch any of your actual prop files. Your default.prop (and any other prop files) are going to be exactly as they were before enabling MagiskHide or changing prop values with MagiskHide Props Config.
Magisk does these things systemlessly, which means it doesn't actually alter the files. This (default.prop) is not your issue... How did you come to the conclusion that Magisk had changed your prop file anyway?
Since you've uninstalled Magisk and the modules, and even updated your OS and the problem still persists it is unlikely that it's directly related to Magisk. I know very little of MIUI though, so I'll leave the rest of the troubleshooting to those that do.
Click to expand...
Click to collapse
I see a difference between my file and my wife's, although the phones are identical and had the same version of the operating system.
Originel - ro.bootimage.build.fingerprint=xiaomi/ginkgo/ginkgo:9/PKQ1.190616.001/V11.0.2.0.PCOINXM:user/release-keys
Actual - ro.bootimage.build.fingerprint=Xiaomi/omni_ginkgo/ginkgo:16.1.0/PQ3B.190801.002/5:eng/test-keys
Maybe I'm wrong, I'm trying different options...
In the end, I'm only interested in being able to access the decrypted content from /data and /sdcard (the internal phone storage) to backup them. Later I will reinstall everything.
Please help me with some tips, ideas, what else can I do?

If I reinstall the same version of MIUI, TWRP and use the same pattern can I decrypt the data (If I finally manage to backup them).

I'm already trying without success for about 2 days, do you think there is any chance to recover the DATA and/or internal storage (most important)?
Or to transfer it encrypted and then set the same pattern and eventually restore the data after I format and reinstall everything?
If I reinstall the same version of MIUI, TWRP and use the same pattern can I decrypt the data?

Adi H. said:
I see a difference between my file and my wife's, although the phones are identical and had the same version of the operating system.
Originel - ro.bootimage.build.fingerprint=xiaomi/ginkgo/ginkgo:9/PKQ1.190616.001/V11.0.2.0.PCOINXM:user/release-keys
Actual - ro.bootimage.build.fingerprint=Xiaomi/omni_ginkgo/ginkgo:16.1.0/PQ3B.190801.002/5:eng/test-keys
Maybe I'm wrong, I'm trying different options...
In the end, I'm only interested in being able to access the decrypted content from /data and /sdcard (the internal phone storage) to backup them. Later I will reinstall everything.
Please help me with some tips, ideas, what else can I do?
Click to expand...
Click to collapse
That fingerprint wasn't set by Magisk... Looks to me like you've been running a third-party/custom ROM and then didn't do a clean install of MIUI when going from the custom ROM. If so, that's a very likely source of the issues. I'm just guessing wildly though...

Didgeridoohan said:
That fingerprint wasn't set by Magisk... Looks to me like you've been running a third-party/custom ROM and then didn't do a clean install of MIUI when going from the custom ROM. If so, that's a very likely source of the issues. I'm just guessing wildly though...
Click to expand...
Click to collapse
Until 14.01.2021 when Revolut no longer worked on rooted phones, I had the MIUI India 11.0.2.0 version installed. Nothing else. Later in trying to make it work I kept switching between various official versions 11.0.2.0 / 11.0.6.0 and 12.0.1.0, flashed thru TWRP or Mi Flash (with save user data method).
It worked perfectly until I made those settings described in the original post. The problem is elsewhere, I think.

Based on the information in the attached file are the system encryption keys generated based on software or hardware?
Because if is hardware, I still have a chance to recover something, but if it's software, the fact that I tried to switch between versions decreases my chances to recover something.
What do you think?

Didgeridoohan said:
That fingerprint wasn't set by Magisk... Looks to me like you've been running a third-party/custom ROM and then didn't do a clean install of MIUI when going from the custom ROM. If so, that's a very likely source of the issues. I'm just guessing wildly though...
Click to expand...
Click to collapse
After I upgraded to MIUI 12.0.1.0 with MiFlash now I can't downgrade to 11.0.2.0. In logs everything seems to be ok, but the phone don't boot entering in recovery.
Trying to flash any other custom ROM, do you thing may be a solution? Or I will make things worse?

How can I resolve this situation?
If the fingerprint is the problem of FBE decrypting, how to restore the correct prop.default file?
Is any recovery that allow me to edit this file like text?
I have a copy of original prop.default.

Hey, did u mange to find a workaround? Im having the same issue, so frustrating!