[Q] Advice on updating rooted FTV without going to 51.1.2.0 to - Fire TV Q&A, Help & Troubleshooting

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.

Related

Owner/Account on B&N Store "Demo Devices" are very stubborn

I've been rooting a lot of nooks lately... around 60 of them so far. Some of the nooks I've purchased turned out to be the in-store demo devices. These models just run a loop, advertising the features. My procedure has been:
-using NookManager, reset to the factory image, this wipes out the advertising loop app
-register all the devices to the same email address, for uniformity
-upgrade the devices to 1.2.1 via usb
-use NookManager to root the device
-install my software
However, I've recently come across half a dozen nooks where the factory image IS the advertising loop. These devices are still rootable, however, they are preconfigured in their factory image with their "TEST NOOKUSER" owner and "[email protected]" account email address. In addition, the "Erase and Deregister Device" option is grayed out.
Summary of unusualness:
-adb via USB not recognized (ADB works via wifi inside NookManager)
-owner/account not editable
-screen time out greyed out at 2 minutes
-adb install -r pickyourfavorite.apk yields "/system/bin/sh: pm: not found" so this renders installing impossible
For the curious, these units are generally 1.0.0 or 1.1.0 software versions.
What are the ideas on the way forward here? I'm sure a lot of these demo devices will be hitting flea markets.
Anders
Anders
I wonder if it would be possible to flash 1.2.1 using CWM? Perhaps that would get you out of the demo loop. I have never tried anything like this, so it is just speculation.
I'd try the unbricking procedure in this thread.
Essentially, you want to save the rom partition from the problem device. Then restore an image from a properly working device. Then restore the rom partition. The thread doesn't go into fixing the rom partition data backup that is in the factory partition in rombackup.zip. Depending on what you're doing with the NST you might want to restore that as well when you're done. Come to think of it, you might want to look at that zip file before you do anything. Unzip it and see if devconf/OperatingMode has Normal in it. If not, change it and zip it back up then do your factory restore.
David0226 said:
I wonder if it would be possible to flash 1.2.1 using CWM? Perhaps that would get you out of the demo loop. I have never tried anything like this, so it is just speculation.
Click to expand...
Click to collapse
Yup, it's absolutely possible to upgrade them to 1.2.1 using the "copy over via USB" method.
Does not get rid of the demo loop though.
Anders
Isn't demo mode just here?
Code:
sqlite3 /data/data/com.android.providers.settings/databases/settings.db
update system set value=0 where name='demo_mode';
.q
If Renate's idea doesn't work, you could try booting into NookManager and connecting using ADB. Once in an adb shell, you can mount the device's internal /system partition using this procedure:
mkdir /int_sys
mount -o rw /dev/block/mmcblk0p5 /int_sys
At this point, try going into /int_sys/app and renaming DemoMode.apk so that when the Nook boots and tries to enter the DemoMode, it can't because the app is gone. This should at least get you access so that you can make other necessary changes.
factory resetting via stock recovery worked for me
i had this problem with one of the nooks i found on ebay. i had to change OperatingMode in rom partition to Normal, and do a factory reset to get out of demo mode. I didn't bother fixing the romrestore.zip

castrated aftv

I castrated one of my aftvs; through an incredibly bone-headed series of events I disabled adbd AND left myself without an alternate entryway for repairs (terminal or ssh). Now I have an aftv that Amazon would love -- no sideloading at all, device only usable for Amazon content. It's stuck on 51107.
I was hoping that the new software update would make it whole (if unrootable), but when I check for new software update I get nada.
jocala said:
I castrated one of my aftvs; through an incredibly bone-headed series of events I disabled adbd AND left myself without an alternate entryway for repairs (terminal or ssh). Now I have an aftv that Amazon would love -- no sideloading at all, device only usable for Amazon content. It's stuck on 51107.
I was hoping that the new software update would make it whole (if unrootable), but when I check for new software update I get nada.
Click to expand...
Click to collapse
If you can play content why can't you go into settings and re-enable ADB?
kairnage said:
If you can play content why can't you go into settings and re-enable ADB?
Click to expand...
Click to collapse
It's not that simple. The problem involves a script running adbd as root after boot. Running adbd as root lets you do some cool stuff you can't do otherwise. Worked pre-boot, failed post-boot, leaving the box w/o adbd. Sucks to be me
Anyway, if you're going to play with internals, have a back door enabled. Lesson learned here, thought I'd pass it on. Locked bootloaders stink.
what about booting to recovery menu, clearing cache, restoring to factory defaults from there? Surely that would un**** your system?
jocala said:
I castrated one of my aftvs;
Click to expand...
Click to collapse
ROFL...sorry, I feel your pain, but I love the subject line...can't stop laughing.
:laugh::laugh::laugh::laugh::laugh:
roligov said:
what about booting to recovery menu, clearing cache, restoring to factory defaults from there? Surely that would un**** your system?
Click to expand...
Click to collapse
Nope
The problem lies in the install-recovery-2.sh script. Restoring to factory default doesn't seem to touch /system/etc.
jocala said:
Nope
The problem lies in the install-recovery-2.sh script. Restoring to factory default doesn't seem to touch /system/etc.
Click to expand...
Click to collapse
Unfortunately, if there is a problem in /system and you can't get a root shell, there really isn't anything that can be done. There is no way to force recovery to use an update.zip because there is no way to get it on there, and that's the only way to get recovery to write to /system. The only solution I know is to mount the emmc chip in linux and fix the /system partition: http://forum.xda-developers.com/showpost.php?p=55280958&postcount=254
rbox said:
Unfortunately, if there is a problem in /system and you can't get a root shell, there really isn't anything that can be done. There is no way to force recovery to use an update.zip because there is no way to get it on there, and that's the only way to get recovery to write to /system. The only solution I know is to mount the emmc chip in linux and fix the /system partition: http://forum.xda-developers.com/showpost.php?p=55280958&postcount=254
Click to expand...
Click to collapse
Yep. Thanks for the link to gtvhacker. I wasn't aware of that method.

Shield Android TV rooted

I just managed to get TWRP running on the new Shield console, and installed SuperSU successfully. Two caveats: the display is upside down, and the USB host ports don't work. I had to plugin a mouse via an OTG cable in order to interact with it. ETA: That's only an issue when booted to TWRP. Everything's working fine in the stock ROM after rooting.
Procedure:
- enable developer tools / USB debugging
- adb push supersu.zip /sdcard
- adb reboot bootloader
- fastboot oem unlock
- fastboot boot twrp-2.8.6.0-shieldtv-unofficial.img
- unplug USB cable, connect mouse via USB, install SuperSU
TWRP boot image is attached. Off to explore...
EDIT: by request, some more detailed instructions:
On the Shield device, head to Settings -> About, and click "Build number" 7 times. This will enable Android's Developer options.
Go to Settings -> Developer options, and enable USB debugging.
Install the ADB/fastboot drivers and utilities if you don't already have them. When "adb devices" shows your Shield, you're good to go.
Download and extract recovery.zip from this thread.
Head to the SuperSU forum and download the latest version.
Open a command prompt and navigate to the directory where you downloaded everything. (Google this for your OS if you don't know how).
With the Shield still booted, run "adb push supersu.zip /sdcard" (change supersu.zip to appropriate file name). This will upload the SuperSU update zip to your device, which you'll install from TWRP.
If that worked fine, run "adb reboot bootloader". Your device should shut down, and display the Fastboot screen after a few seconds.
FOLLOW THE NEXT THREE INSTRUCTIONS AT YOUR OWN RISK. This WILL wipe all your user data, back it up with ADB first if you want to preserve it. DISCLAIMER #2: I have no idea if there are any DRM keys or anything that get wiped when this is done (this was the case on my Xperia Z3 Compact). I will say that Grid streaming still works fine after doing this.
This step will unlock your bootloader to enable booting unsigned images.
Run "fastboot devices" and make sure your Shield is visible.
Run "fastboot oem unlock" and follow the prompts on the screen. Your bootloader is now unlocked.
Now, boot the TWRP image with: "fastboot boot twrp-2.8.6.0-shieldtv-unofficial.img" - Note: I used this instead of "fastboot flash" so I could keep the stock recovery around, to grab an image of it after rooting.
You should now see a TWRP recovery menu (upside down for now).
Connect a keyboard or mouse via OTG cable, and select "Install", navigate to your SuperSU zip, select it, and follow the prompts.
Click "reboot" and you should now be rooted.
Great job. Will try later.
It offers fastboot OEM unlock?!? Sweet
I'm starting dev work on this as well. Can you try the flipped screen flag and see if it that fixes the display? That's required to make the tablet work correctly. I preordered the pro edition, so I can't test anything for almost another two weeks. Hopefully someone will be able to get the normal usb ports working, since it'll be much easier to use those for a mouse/keyboard.
Sweet can't wait to try this out
Thanks for posting this. I've got my NVIDIA Shield Android TV coming on Wednesday, so I'll give this a try. I had a USB OTG cable, but lost it several months ago so I ordered another one of those as well. Just to clarify... the 2 USB 3.0 ports will work after rooting when you boot back to stock, right?
Also, this works on the latest 1.1 OTA update too, correct?
Sorry to ask this as it is super n00bish, but could someone explain to me step-by-step directions for rooting this or perhaps link to a guide that uses this same procedure? I know the main steps are listed in the OP, but I'm not really sure how to use adb to push supersu.zip, reboot into bootloader, fastboot, etc.
Lastly, what will be the process of upgrading via OTA updates in the future after I root it? Will I need to unroot one way or another (instructions or a link to a guide would be great), or will OTA updates work just fine?
Once again, sorry for all the n00b questions. I just want to make sure I don't do something stupid to mess the device up...
FreeEmulator said:
Thanks for posting this. I've got my NVIDIA Shield Android TV coming on Wednesday, so I'll give this a try. I had a USB OTG cable, but lost it several months ago so I ordered another one of those as well. Just to clarify... the 2 USB 3.0 ports will work after rooting when you boot back to stock, right? Also, this works on the latest 1.1 OTA update too, correct?
Also, sorry to ask this as it is super n00bish, but could someone explain to me step-by-step directions for rooting this or perhaps link to a guide that uses this same procedure? I know the main steps are listed in the OP, but I'm not really sure how to use adb to push supersu.zip, reboot into bootloader, fastboot, etc.
Click to expand...
Click to collapse
Yup, everything works normally after rooting. These issues only exist in TWRP because I did an extremely quick and dirty build (extracted a Shield Tablet TWRP and replaced the kernel). I'll work on fixing them soon, unless someone beats me to it. Thanks for the tip on the screen flipping, Steel01.
I've updated the OP with some more detailed instructions.
ETA: I can't see OTAs being a problem. In theory, they could check if an su binary is installed and deny the update until you remove it, but if they're allowing oem unlock, I can't see why they'd do that. And you could just remove it anyway. You will have to re-root after each OTA update.
teletype said:
Yup, everything works normally after rooting. These issues only exist in TWRP because I did an extremely quick and dirty build (extracted a Shield Tablet TWRP and replaced the kernel). I'll work on fixing them soon, unless someone beats me to it. Thanks for the tip on the screen flipping, Steel01.
I've updated the OP with some more detailed instructions.
ETA: I can't see OTAs being a problem. In theory, they could check if an su binary is installed and deny the update until you remove it, but if they're allowing oem unlock, I can't see why they'd do that. And you could just remove it anyway. You will have to re-root after each OTA update.
Click to expand...
Click to collapse
Awesome, thank you so much for the info and instructions. :good: I should be good to go now once everything arrives on Wednesday.
Twrp for forge?
Is there any skilled folks out the with a forge tv? I'm in need of some kind of recovery for this. I'm a bit of a noob so compiling it on my own is kinda greek to me
Quick warning for Pro owners: OEM Unlock takes about 92 minutes. Just be warned and ready for it...
Yeah so go to links with viruses in them and then waste time removing them. You know there are website without a million links to viruses all over them that can be used. It's always nice not to have to play guess which download link isn't a virus. -_-
i read somewhere that full hd/4k playback in netflix and other vod services needs a locked bootloader. is that right?
A.N.Droid said:
i read somewhere that full hd/4k playback in netflix and other vod services needs a locked bootloader. is that right?
Click to expand...
Click to collapse
Hypothetically if you can oem unlock bootloader can you just oem lock bootloader to fix the issue?
teletype said:
ETA: I can't see OTAs being a problem. In theory, they could check if an su binary is installed and deny the update until you remove it, but if they're allowing oem unlock, I can't see why they'd do that. And you could just remove it anyway. You will have to re-root after each OTA update.
Click to expand...
Click to collapse
Actually rooting will likely break OTA updates. Since lollipop, Google has moved to block level OTA updates. That means it doesn't just patch individual files, it patches at the block level. So if there is a change to /system the OTA won't update.
The same seems to apply to the Shield TV. Here's the updater-script from the current OTA:
Code:
(!less_than_int(1432624016, getprop("ro.build.date.utc"))) || abort("Can't install this package (Tue May 26 00:06:56 PDT 2015) over newer build (" + getprop("ro.build.date") + ").");
getprop("ro.product.device") == "foster" || abort("This package is for \"foster\" devices; this is a \"" + getprop("ro.product.device") + "\".");
show_progress(0.750000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/platform/sdhci-tegra.3/by-name/APP", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
show_progress(0.050000, 5);
package_extract_file("boot.img", "/dev/block/platform/sdhci-tegra.3/by-name/LNX");
show_progress(0.200000, 10);
nv_copy_blob_file("blob", "/staging");
nv_copy_blob_file("bmp.blob", "/bmps");
But borked OTA shouldn't be much of an issue, since Nvidia is releasing the fastboot factory images: https://developer.nvidia.com/shield-open-source The text is there now for them, but they aren't up yet. So you can always revert to stock, then OTA update.
Wait... What? You got one of of the tablet twrps to boot on the console? I'm shocked that worked. Didn't think it what that easy to get 32-bit mode. Anyways, that's why it's upside down, because that flag is set for the tablet. As soon as a console section opens up here and on androidfilehost, I'll post my builds. I have cm, twrp, and multirom compiling, but I can't test them until next week, when Amazon ships the pro, so they might not even boot.
@agrabren: Oh my goodness, the wipe takes that long? What's it doing? US Government certified nuking? And people complain about multi minute cache wipes on the tablet now. What am I going to be hearing in a couple weeks for this?
Actually, since you're around again... Do you still have the CM files you made for the portable? I'm still interested in what you did to make the cwm recovery work as well as it did.
One more quick question for now... once rooted, does anyone know how I would go about locking the GPU clock speed / frequency at its highest setting (which if I've read correctly is 1 GHz)? I'd like to be able to flip the lock on only while testing out some pretty hardware intensive emulator games (the Dolphin GameCube/Wii emulator, which I was told by a developer of the emulator to try to lock the maximum GPU clock speed to ensure best performance). Thanks again for all the help, you guys are great.
Tested out the pro console on my side (Got it early due to reasons).
It refuses to mount any partitions, so it is impossible to root.
sonicadvance1 said:
Tested out the pro console on my side (Got it early due to reasons).
It refuses to mount any partitions, so it is impossible to root.
Click to expand...
Click to collapse
It's probably because the partition layout/names are different for the internal 500GB drive. If you poke around you can probably find the info, or just dump your boot.img, decompile it and look for the fstab file. It will look similar to the below (that is for the ADT-1).
Code:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/sdhci-tegra.3/by-name/system /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/cache /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check
/dev/block/platform/sdhci-tegra.3/by-name/userdata /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/crypto
/dev/block/platform/sdhci-tegra.3/by-name/misc /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/boot /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/recovery /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/DTB /dtb emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/staging /staging emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/sysdata /sysdata emmc defaults defaults
Someone skilled do this also for Forge anyways hopefully XDA adds Android TV forums.
Keep up the good work even though I don't own the Shield.
patt2k said:
Someone skilled do this also for Forge anyways hopefully XDA adds Android TV forums.
Keep up the good work even though I don't own the Shield.
Click to expand...
Click to collapse
The forge has a locked bootloader. Sure, you can root it (supposedly), then replace the recovery, but you'll never be able to use fastboot until it's unlocked.
BTW, the Nvidia Shield TV factory images are up now :victory:

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.

[QUESTION / CONCEPT] Running Netlfix HD on rooted Tab S3 (fix for Widevine L1 DRM)

I wanted to ask you for help in getting Netflix running in HD/HDR on tampered Tab S3 (as well as Google Movies, player.pl and other media streaming services using Widevine L1).
I have analyzed the problem in details and I am convinced that it is possible. Unfortunately, I have stuck in my testing due to the problem described below. Maybe anyone has an idea how to solve it...
L1 Widevine DRM is hardware-based device-specific media encryption engine which - in short - allows you to play HD movies along with all the fancy stuff like HDR and surround. L1 engine requires a factory-provisioning certificate which should be placed in
Code:
/data/mediadrm/IDM1013/L1/cert.bin
The point is that the certificate is part of stock ROM and it is being flashed via Odin from the image of stock, encrypted /data partition (if you extract an Odin image, it is a userdata.img file). The firmware image is the only source of that file; in particular, it cannot be generated in any other way, using any algorithm. It has to be provided through the factory firmware.
We want to read the contents of the cert file - i'll explain why in a second. Unfortunately:
- userdata.img is encrypted and cannot be mounted/dumped with any external tool; so we cannot get the file straight from the image;
- after flashing stock rom the /data partition cannot be mounted with TWRP (Samsung-crypto still not supported...) thus the file cannot be accessed via recovery;
- after booting stock ROM, the encrypted /data is mounted and the file is there. However, I still cannot get the copy of the file via shell/adb due to lack of privileges for unrooted user!
- the /data encryption on Samsung devices depends on boot image integrity. Thus rooting the device - which in fact require boot image tampering in order to install SuperSu or Magisk - will result in system not booting and an error in decrypting the /data partition. Cert file still cannot be accessed.
- to run the [rooted] system using the tampered boot image, it is required to format the /data and disable the encryption first. After that the device will boot and will be rooted - but /data/mediadrm/IDM1013/L1/cert.bin will not exist, as we have just formatted whole /data partition!
- to restore the file, one has to flash the full stock ROM, along with encrypted /data, in Odin again - but this will re-enable the encryption and the whole story begins again...
On rooted device, Netflix (and other such apps) checks if liboemcrypto.so exist in the system (it is a library responsible for that L1 DRM support). If yes, it assumes that L1 DRM is available so it tries to decrypt streams in HD, but fails - because there is no /data/mediadrm/IDM1013/L1/cert.bin file, which is required for decryption (you can easily confirm my theory via logcat). This is why the workaround for running Netflix on rooted devices is to delete that liboemcrypto.so library - however, it will disable whole L1 decryption engine. After that, Netflix will proceed to run in L3 mode, which doesn't require factory provisioning; unfortunately, L3 mode is much worse and it does not support anything but SD. That is why deleting liboemcrypto let you run Netflix app at all - but that is also the reason of the low video quality.
If L1/cert.bin does exist, liboemcrypto - at least in theory - shouldn't fail, L1 shall work and HD content shall be possible to be played. So, the aim is to backup the file /data/mediadrm/IDM1013/L1/cert.bin from the encrypted /data that comes along with the stock ROM and restore it after rooting and formatting /data. I haven't found a way to do it, though.
That is why I wanted to ask you guys if you have any idea how to get the /data/mediadrm/IDM1013/L1/cert.bin file from the stock unrooted ROM - as copying it back to the device after rooting it might be the ultimate solution for all that no-HD no-HDR no-anything Netlfix issues, which we all are looking for I guess.
So my question is: is anyone aware of an exploit (like dirtycow), trick or any other method which will be compatibile with stock Samsung ROM and will allow me to dump the contents of that file without root?
Or anyone knows an alternate method of reading the contents of Samsung-encrypted /data partition (in order to read the file)?
PS: don't mistake L1/cert.bin with L3/cert.bin. The latter one is for SD playback and even if deleted, it is being automatically generated on every boot and can be accessed after rooting.
Are you sure Netflix doesn't run in HD on rooted device? It looks HD to my eyes. I do believe you are right about hdr not working on a rooted tab s3. This is interesting.. I'm going to flash a stock rom to see the difference. Please keep us updated.
Yeah I see the difference..the screen on this tab is amazing.
With root the max resolution is 960x540
another reason I would never root this tablet..
Any luck on finding a way to get HDR enabled with a rooted s3 tab?
take a look to this thread:
https://forum.xda-developers.com/showpost.php?p=75465158&postcount=132
the are forcing the L1 on a modded Netflix apk.
I'm not sure if Its working.
Any help from TWRP team?
I've already expressed this in other thread:
At least in my case, being rooted without libcryptoem and L3 status isn't breaking the HDR support for streams.
And, unless my eyes are fooling me, it looks like HD is working fine too.
The only problem so far is for the offline feature.
You can only download SD files for offline view unless you're on L1.
EDIT: I watched more stuff just in case and, even if the app is stating HDR before playing, unfortunately it's not HD, the L3 thing is affecting streams and downloads. I thought it was just downloads.
JWnSC said:
Are you sure Netflix doesn't run in HD on rooted device? It looks HD to my eyes. I do believe you are right about hdr not working on a rooted tab s3. This is interesting.. I'm going to flash a stock rom to see the difference. Please keep us updated.
Yeah I see the difference..the screen on this tab is amazing.
With root the max resolution is 960x540
Click to expand...
Click to collapse
how we can measure the resolution using netflix app??
The userdata image from the Odin package is not encrypted. It can be extracted with:
Code:
unzip ../SM-T820_1_20180523135714_8qsl9aro0u_fac.zip
tar xvf AP_T820XXU1BRE2_CL13482624_QB18016528_REV00_user_low_ship_MULTI_CERT_meta.tar.md5
lz4 -d userdata.img.ext4.lz4
simg2img userdata.img.ext4 userdata.img
7z x userdata.img
(on the T820XXU1BRE2 firmware)
The list of files inside the image are here: https://gist.github.com/chenxiaolong/94bbeff18e3b6b3e3714cbad46841274
Maybe /data/mediadrm/IDM1013/L1/cert.bin is generated during the first boot if the unmodified stock firmware is used?
chenxiaolong said:
Maybe /data/mediadrm/IDM1013/L1/cert.bin is generated during the first boot if the unmodified stock firmware is used?
Click to expand...
Click to collapse
It is generated when you're trying to play drm content for the first time. Like L3 stuff.
If I test it right, L1 depends on /data partition encryption status.
bonuzzz said:
It is generated when you're trying to play drm content for the first time. Like L3 stuff.
If I test it right, L1 depends on /data partition encryption status.
Click to expand...
Click to collapse
Interesting.. It may be possible to retrieve it then. When first flashing Oreo the only way to get it to boot was with encryption enabled and magisk. I did check for L1 on the data partition, didn't see it but hadn't attempted to play Netflix yet. It's late now I'll check tomorrow. Thanks
Nope..didn't think about dm-verity disabled.. didn't work
JWnSC said:
Interesting.. It may be possible to retrieve it then. When first flashing Oreo the only way to get it to boot was with encryption enabled and magisk. I did check for L1 on the data partition, didn't see it but hadn't attempted to play Netflix yet. It's late now I'll check tomorrow. Thanks
Nope..didn't think about dm-verity disabled.. didn't work
Click to expand...
Click to collapse
I also tried to encrypt data partition in lineage and got it working there, but unsuccessfully. The same error as we have in rooted stock tw rom. Probably it also checks official/custom status, but honestly I doubt.
Use Magisk Hide to hide root from Netflix.
Results?
lupick said:
how we can measure the resolution using netflix app??
Click to expand...
Click to collapse
Search Netflix video "Test Pattern".
It will show u lists of videos with different framerates.
Play any of those, u will see on the top right of the video the actual bitrate + resolution the video is rendered.
Thats how you can check if ur current netflix app is playing hd or not.
Note:
I think Not all regions have TEST PATTERN videos for netflix.
Why not to let Netflix think you have a Pixel 2 instead of a Galaxy Tab S3. I use it for a few months now and works much better then expected.
Change the row "ro.product.model" in "/system/build.prop" to "pixel 2". then save and reboot. Netflix will be installable from playstore without any issues in use. Streaming is very fast and display quality is amazingly good.
Code:
ro.product.model=pixel 2
wase4711 said:
another reason I would never root this tablet..
Click to expand...
Click to collapse
Btw which tablet ..??
Means if it's mtk then there is a way ...
Without unlocking bootloader using some leaked informations

Categories

Resources