Related
Firstly a big thank you macexplorer who again found the relevant links amongst much Japanese.
See the original thread on rooting the F-01D:
http://forum.xda-developers.com/showthread.php?t=1611484
Following are quick instructions on how to upgrade the device to ICS. All your data will remain intact, but the /system partition is completely wiped.
NB: YOU WILL LOSE ROOT IF YOU FOLLOW THESE INSTRUCTIONS. YOU WILL NOT GET ROOT BACK.
To be clear, at the present moment in time, you need to CHOOSE BETWEEN ICS OR ROOT, you can't have both. The official upgrade below completely reflashes the system partition, so tools like OTA RootKeeper will not help you. The new release is more secure than ever and at current we don't know a new way to get root. If anyone finds any new information, please speak up
DISCLAIMER: Following these instructions might brick your device, void your warranty, etc. This is unlikely since you're basically installing an official update, but to be clear, I disclaim any and all responsibility for any (permanent) damage that might be caused by these instructions. DO AT YOUR OWN RISK.
The original instructions are here (or see in Google Translate)
http://spf.fmworld.net/fujitsu/c/update/nttdocomo/f-01d/update1/top/index.html
My instructions are slightly different, aimed at more advanced users, and serves the file direct from my server (I found the original server quite picky in terms of refer and user agent, and also slow. I'm also serving the unzipped version, since compression was 0% anyways).
PRE-REQUISITES
At least 50% battery (ideally more in case things go wrong...).
Settings -> About, make sure Android version is 3.2, and Build number is either V28R43A (as recommended on the official page) or V19R36D (what I had; it worked for me but YMMV).
Settings -> Storage, at least 1.5 GB free in "Built in storage" (try installing first to external SD card and let me know if it works.. it's a lot safer).
ICS UPGRADE FOR F-01D
Download F01D_TO_SP_ICS1.enc and put it in /sdcard (md5sum: 2014d0254568a4ef955b21476012a9b5)
Boot into recovery (power off, hold down both volume keys and power up), select "update firmware" and press the power button agin.
Pay attention... the first time I tried this, it rebooted back in to recovery part way.... if this happens, just repeat step 2 above and make sure the progress bar completes all the way.
After this, it will reboot a few times, don't worry. Boot 1 will do the "optimizing android apps" screen, Boot 2 will be "upgrading calendar, contacts, etc..." and Boot 3 will say "finishing upgrade" and let you use the system.
If anyone has any leads on re-rooting the device, speak up. From my initial observations security is tighter than ever, so this might be a problem... but there are clever people out there
Regarding root
No leads for now. We can create /data/local.prop using the ICS/JB restore technique, but unfortunately the new firmware is completely ignoring either this file or the ro.kernel.qemu property.
If I understood the google translated Japanese correctly, this guy got to the same conclusion, and is now looking for other solutions. I wish him luck because after spending the day on this I have to get back to my real work
http://blog.huhka.com/2012/09/arrows-tab-lte-f-01d-icsshell-root.html
Temporary Root
This link in xda works to get a temporary root:
http://forum.xda-developers.com/showthread.php?t=1886310
i think to get permanent root, need the lsm_disabler.ko for ICS kernel.
Update:
ICS kernel has blocked loading kernel modules; so cannot insmod a custom kernel.
so cannot remount /system, and cannot get permanent root..
shame on the dandroids..
Post upgrade restart errors?
Hi, slightly off-topic but related - has anyone had issues after upgrading with google maps? Whenever I start google maps it will hang and then restart my tablet.
Essentially google maps is now unusable which is very annoying. Please let me know if anyone has experienced this too and if so if they have a solution to the problem.
Many thanks in advance!
I lost boot after upgrade the device to ICS :crying:
anyone help me repaid boot
Thanks:laugh:
longdau12 said:
I lost boot after upgrade the device to ICS :crying:
anyone help me repaid boot
Thanks:laugh:
Click to expand...
Click to collapse
Help me :crying:
macexplorer said:
This link in xda works to get a temporary root:
http://forum.xda-developers.com/showthread.php?t=1886310
i think to get permanent root, need the lsm_disabler.ko for ICS kernel.
Update:
ICS kernel has blocked loading kernel modules; so cannot insmod a custom kernel.
so cannot remount /system, and cannot get permanent root..
Click to expand...
Click to collapse
FINALLY..ROOT on F-01D for V08R31A
I hope someone is still using the F-01D. So here's to you diehards.
After many many failed attempts, i finally managed to get a more permanent root.
Probably others have got this to root, but I havent seen anything come up via searches.
Main stumbling block has been in getting the address of 'ptmx_fops'. Finally got it thro, rootkitXperia_20131207.zip (get_root..this prints but fails in ptrace; ptrace is blocked in f01d)
I have just managed to get a permanent root. The steps maybe little approx. Do verify and let me know. Its non-destructive, so no harm done.
but do at your own risk..and other standard disclaimers apply
Steps:
1. do the temp root as per : http://forum.xda-developers.com/showpost.php?p=33071441&postcount=3
2. get the exploit source from https://github.com/fi01/unlock_security_module
(recursive download)
3. compile the source. this will generate a libs/armeabi/unlock_security_module binary
4. add the following recs to the device_database/device.db
these are kallsyms kern func addresses; most are avail direct from kallsyms, except for ptms_fops.
Code:
sqlite3 device_database/device.db
insert into supported_devices values(187,'F-01D','V08R31A');
insert into device_address values(187,'commit_creds',3221986012);
insert into device_address values(187,'prepare_kernel_cred',3221985196);
insert into device_address values(187,'ptmx_fops',3229222484);
insert into device_address values(187,'remap_pfn_range',3222251308);
insert into device_address values(187,'vmalloc_exec',3222293708);
5. push device.db and unlock_security_module to /data/local/tmp/
6. simply run from /data/local/tmp: ./unlock_security_module as the root obtained temp earlier.
7. after sometime, this will say LSM disabled!!
8. now remount /system as rw. carefully copy su binary to /system/xbin/ (pref use the latest version from SuperSu).
Also copy Superuser.apk to /system/app
>>carefully copy means: chown/chgrp /system/xbin/su to "0"; set perms: chmod 06755 /system/xbin/su.
9. copy busybox from /data/local/tmp to /system/xbin; and install (./busybox --install -s /system/xbin/
10. At this stage, su doesnt seem to work for newer shell connections (must do _su and then su). probably due to the exploit messing up the kernel.
11. reboot. and enjoy your newly permanent rooted status.
12. after reboot, still cannot do system remount as lsm is back to original. rerun the unlock_security_module should disable this.
maybe even move this to /system/xbin/;
But this seems to destabilise the system.
Its not possible to use a lsm disabler ko insmod. the kernel sec mech validates the module with path and hash.
So it has to be: unlock security; do your thing with /system etc., reboot.
(not sure yet if any changes to /system/buid.prop will help)
Do let me know how this works out and point out errors in the steps.
And as luck would have it there is a new ICS release out on 5-Feb.
https://www.nttdocomo.co.jp/support/utilization/product_update/list/f01d/index.html
http://spf.fmworld.net/fujitsu/c/update/nttdocomo/f-01d/update1/top/data/download.html
(F01D_TO_SP_ICS2.zip)
This moves the version to V12R33B.
Do not hazard to update to this, if you want to keep this root. this release probably fixes many of the exploits.
the wifi model seems to have got 4.1..wonder is something will trickle down to f01d.
[TOOL][HOW-TO] [N7] [grouper+tilapia] BootUnlocker Script [Flashable Zip]
BootUnlocker Script for Nexus 7 (2012) -- Unlock your bootloader without fastboot.
Important Information
Those of you with any of the other recent flagship Nexus devices (Galaxy Nexus onward) may already be familiar with the brilliant work of segv11 in creating the BootUnlocker for Nexus Devices app. His app uses root to flip a byte on a device partition, allowing you to relock your bootloader for security and unlock it again any time you wish without the data loss that would come from unlocking via fastboot. I have also followed segv11's method and created a recovery flashable zip for the same devices available from my Odds & Ends thread.
Through the work of myself and several others in the GN BootUnlocker App thread it has been found that the data which controls the lockstate for the N7 '12 is stored in the mmcblk0boot0 partition. Unfortunately we also found this data cannot be simply altered to change the lockstate of the N7 '12 (like it can with the other Nexus devices) due to encryption on a per-device basis. The encrypted data also changes with each new version of the bootloader. The complicated nature of the key means that it's unlikely that the encryption could ever be cracked.
There is, however, still a working solution. Even though your mmcblk0boot0 partition is uniquely encrypted for your device, I found it also changes exactly the same way each time you lock or unlock your bootloader. This means if you back up your mmcblk0boot0 partition when your device is both unlocked and locked, you can simply flash these partition dumps whole to change the lockstate, with no data loss. That's where my script comes in.
In this How-To we are going to make dumps of your mmcblk0boot0 partition in both lockstates, then alter my included zip and updater-script using the dumps so that you have a fully functioning BootUnlocker Script recovery flashable zip tailored to your specific device. When flashed, this zip will lock or unlock your device (depending on what state it's currently in), whenever you want with no data loss.
Requirements
Nexus 7 (2012) grouper/WiFi or tilapia/GSM-HSPA+ (both use the exact same bootloader).
An UNLOCKED bootloader (if locked you'll need to fastboot oem unlock first which WILL factory reset your device).
Bootloader version 4.23 (if newer, then you'll also need to follow the steps to update the bootloader check, found in the 3rd post).
Custom recovery (CWM or TWRP) flashed to your device.
adb+fastboot binaries/executables, either from the Android SDK or you can get them standalone from here.
Universal Naked Driver for Android devices recommended installed for both adb+fastboot on Windows machines.
Notepad2, Notepad++, or another text editor capable of keeping the LF (linefeed) format required for Linux/Unix files like the updater-script.
Disclaimers / Warnings (READ)
I am in no way responsible for you somehow messing up these reasonably simple steps and damaging your device. DO NOT attempt this if you do not accept this risk. If you met the above requirements (in particular the unlocked bootloader), then the following instructions will not result in any data being lost in this process. DO NOT post your zips to this thread once you've followed the directions since the zips will not work on other peoples' devices and if another user somehow flashes your dumps by mistake, could damage their device. Each device must have its own specific BootUnlocker Script zip made using the unique dumps that belong to it.
It is critical that you have read all of the above before you move on.
Building Instructions
Instructions
Step 1 - Getting the dumps and their sha1sums:
Start by downloading the zip attached to this post to your PC. Save it for later.
Boot into your custom recovery on your device with it connected, open a command prompt on your PC where you have adb+fastboot.
Ensure the device is recognized by typing "adb devices".
Type "adb shell" in and then do the following, being sure to copy+paste the sha1sum for unlocked to Notepad for later.
Code:
dd if=/dev/block/mmcblk0boot0 of=/tmp/unlocked-mmcblk0boot0.img
sha1sum /tmp/unlocked-mmcblk0boot0.img
exit
adb pull /tmp/unlocked-mmcblk0boot0.img unlocked-mmcblk0boot0.img
adb reboot-bootloader
fastboot devices
fastboot oem lock
Boot to Recovery using the Bootloader menu then "adb shell" in and do the following, again copy+paste the sha1sum for later, this time for locked.
Code:
dd if=/dev/block/mmcblk0boot0 of=/tmp/locked-mmcblk0boot0.img
sha1sum /tmp/locked-mmcblk0boot0.img
exit
adb pull /tmp/locked-mmcblk0boot0.img locked-mmcblk0boot0.img
It's important that the dumps are named correctly according to the lockstate for the script, and equally important you have kept those sha1sums straight and you know which corresponds to unlocked and which is for locked.
Step 2 - Editing the updater-script:
Extract the updater-script (in /META-INF/com/google/android/) from the zip.
It appears as follows, and is written with safety checks for bootloader version and current lockstate to prevent flashing on the incorrect version or device, respectively. It is currently written for v4.23 ONLY of the bootloader. If you update the bootloader or have a newer version you must update all of these checks (instructions in next post).
Code:
ui_print("");
ui_print("Nexus 7 BootUnlocker Script");
ui_print("by osm0sis @ xda-developers");
ui_print("");
ui_print("For N7 bootloader 4.23 ONLY");
ui_print("and the device belonging to <yourname> ONLY");
show_progress(1.34, 0);
ui_print("");
ui_print("Verifying device...");
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
ui_print(getprop("ro.product.device"));
assert(getprop("ro.product.device") == "<devicename>" ||
getprop("ro.build.product") == "<devicename>");
set_progress(0.2);
ui_print("");
ui_print("Verifying bootloader version...");
ui_print(getprop("ro.bootloader"));
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/USP:10485760:8c206a1a87599f532ce68675536f0b1546900d7a"),
getprop("ro.bootloader") == "4.23" ||
getprop("ro.boot.bootloader") == "4.23");
set_progress(0.5);
ui_print("");
ui_print("Checking bootloader status...");
run_program("/sbin/busybox", "dd", "if=/dev/block/mmcblk0boot0", "of=/tmp/current-mmcblk0boot0.img");
ifelse(sha1_check(read_file("/tmp/current-mmcblk0boot0.img")) == "<locked sha1sum>",
(ui_print("Bootloader is locked.");
ui_print("");
ui_print("Unlocking...");
package_extract_file("unlocked-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img");
),
(ifelse(sha1_check(read_file("/tmp/current-mmcblk0boot0.img")) == "<unlocked sha1sum>",
(ui_print("Bootloader is unlocked.");
ui_print("");
ui_print("Locking...");
package_extract_file("locked-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img");
),
(ui_print("Status does not match known values.");
ui_print("This is not the intended specific device.");
ui_print("");
ui_print("Your system has not been changed.");
ui_print("");
ui_print("Script will now exit...");
ui_print("");
delete("/tmp/current-mmcblk0boot0.img");
unmount("/system");
abort();
)
);
)
);
set_progress(0.9);
assert(run_program("/sbin/sh", "-c", "echo 0 > /sys/block/mmcblk0boot0/force_ro"),
run_program("/sbin/busybox", "dd", "if=/tmp/mmcblk0boot0.img", "of=/dev/block/mmcblk0boot0"),
run_program("/sbin/sh", "-c", "echo 1 > /sys/block/mmcblk0boot0/force_ro"),
delete("/tmp/current-mmcblk0boot0.img", "/tmp/mmcblk0boot0.img"));
set_progress(1.2);
unmount("/system");
ui_print("Done!");
set_progress(1.34);
Open Notepad 2/Notepad++ and ensure it is set so that it won't break the LF (Unix) formatting when it saves, then open the extracted updater-script.
Make sure the device check on lines 14+15 matches your device. ie. If you are running a tilapia then you should change them (quotes intact) to "tilapia", likewise for "grouper".
Replace <yourname> on line 7 with your username. eg. the device belonging to osm0sis ONLY
Replace <unlocked sha1sum> on line 35 with the sha1sum for the unlocked dump you saved from Step 1.
Replace <locked sha1sum> on line 29 with the sha1sum for the locked dump you also saved from Step 1.
The sha1sum replacements are the most important. They MUST match the dumps correctly. Also make sure you leave the quotes in the script surrounding the sha1sums intact, eg. "0000000000000000000000000000000000000000"
Save and exit Notepad.
Step 3 - Putting it all together:
Add both .img files to the zip. They should be in the root (top level) of the zip. Make sure they are located correctly.
Overwrite the updater-script in /META-INF/com/google/android/ of the zip with your new edited version. Double check that it has replaced the old one and has been added correctly.
Save and exit the zip.
It is now recommended you name the zip according to the following scheme: cwm-N7.<device>.BootUnlocker.v<bootloaderversion>-<username> to differentiate device, bootloader version and user. Mine is cwm-N7.grouper.BootUnlocker.v4.23-osm0sis.zip. This should help prevent confusion.
Done! You now have a BootUnlocker zip for your N7 '12 until the bootloader gets updated.
Flash it to unlock your device again. Flash it again to lock it.
Previous version download count: 131
Update Instructions
Updating When A New Bootloader Is Released
Once built for your device, the above script will work as long as the bootloader remains at v4.23 (as per the naming). The way I've scripted it, for safety it shouldn't work on any other bootloader version or on anyone else's device, but I'd still advise against trying. Since the encrypted data also changes based on the version of the bootloader, if/when you update the bootloader you MUST also get NEW dumps of the mmcblk0boot0 partition both unlocked and locked.
BEFORE you update your bootloader, if your device is locked, start by using the BootUnlocker Script zip you previously created to unlock.
Update your bootloader to the new version (usually done via OTA or fastboot flash of a Factory Image).
Follow the steps in the 2nd post again to update your zip, replacing the .img files with the new dumps, and altering the update-script with the new corresponding sha1sums.
Change the version number in the updater-script warning on line 6 and the version number check on lines 22+23 to that of the new bootloader, and be sure you have renamed the zip with the new version number as well to keep things straight.
"adb shell" in while booted to custom recovery and run the following, copy+paste the bytesize and sha1sum for the next step.
Code:
dd if=/dev/block/platform/sdhci-tegra.3/by-name/USP of=/tmp/USP.img
sha1sum /tmp/USP.img
rm /tmp/USP.img
Enter the new bootloader's bytesize and sha1sum into the bootloader version check on line 21, in the following format USP:<bytesize>:<bootloader sha1sum>, eg. for v4.23 it is
Code:
USP:10485760:8c206a1a87599f532ce68675536f0b1546900d7a
Enjoy!
Questions, comments and feedback welcome.
Thanks to segv11 and efrant for all the fun in the GN BootUnlocker App thread, scary alien for the help with the bootloader check assert syntax in his OTA Verifier App thread, and thanks to trevd for the update-binary info/help in the GN EDIFY Scripting thread. Also a special thank you to Mach3.2, scary alien, partha and drose6102 for submitting dumps so all this could be figured out, and for basically being the Beta/RC testers for this script. Cheers!
You finally got it working! I ought to try this, of course after wrestling with the grizzly dad of mine. Awesome job there Chris!
Sent from my Galaxy Nexus using Tapatalk 2
Haha yup. I've had it working for awhile now, it was just a matter of writing up this monster guide. Thanks Fitz. Good luck with that wrestling.
Very cool, and very nice work.
osm0sis said:
Since the encryption also changes based on the version of the bootloader
Click to expand...
Click to collapse
The encryption does not change, that is static for the life of the device, what changes is the data stored. Also boot0/1 are technically not partitions and are more analogous to mmcblk0 than mmcblk0px there are 3 partitions that start within this range, BCT, PT and the start of the bootloader. BCT takes up the entire boot0 and part of boot1.
The reason you cannot just flash back your backup copy is a hash of the bootloader is stored in the bct for verification and integrity checking purposes[1]. This changes the end result because all SBK encrypted data is done in AES-128-CBC meaning the previous blocks cipher text is the next blocks IV.
Because of this you should also be careful of any number of other conditions that cause writing to the BCT as they have the potential to cause the decryption to fail on the rest of the BCT which is in mmcblk0boot1. While this may not (and at this point should not) cause bricking, changes made by google in the future may alter this outcome.
[1] The hash stored in BCT not matching the bootloader hash causes the device to fall back into APX mode.
lilstevie said:
The encryption does not change, that is static for the life of the device, what changes is the data stored. Also boot0/1 are technically not partitions and are more analogous to mmcblk0 than mmcblk0px there are 3 partitions that start within this range, BCT, PT and the start of the bootloader. BCT takes up the entire boot0 and part of boot1.
The reason you cannot just flash back your backup copy is a hash of the bootloader is stored in the bct for verification and integrity checking purposes[1]. This changes the end result because all SBK encrypted data is done in AES-128-CBC meaning the previous blocks cipher text is the next blocks IV.
Because of this you should also be careful of any number of other conditions that cause writing to the BCT as they have the potential to cause the decryption to fail on the rest of the BCT which is in mmcblk0boot1. While this may not (and at this point should not) cause bricking, changes made by google in the future may alter this outcome.
[1] The hash stored in BCT not matching the bootloader hash causes the device to fall back into APX mode.
Click to expand...
Click to collapse
Hey great to finally get some more information about the encryption used and the contents of boot0-1. Very interesting stuff. How did you determine this? We couldn't find much documentation on the matter. Any ideas on how to decrypt it would also be greatly appreciated, since that might allow segv11 to still be able to include it in the BootUnlocker app.
So far the only time we've seen the md5hash of the boot0 block change on a particular device is with a bootloader version change, after which it continues to remain consistent depending on lockstate. I was merely guessing that was part of the encryption process but the data changing would of course also make perfect sense, so thank you for that information. What doesn't change when unlocking/locking the bootloader is boot1, so flipping between the two states for boot0 will still keep decryption of boot1 intact.
I definitely understand your concerns that it is a dangerous business writing to these blocks, and I agree, but as you've seen I haven't taken this lightly in either my posts or my script; the script has safeties built in to make sure it only writes to boot0 when it meets one of the two known states for that person's device (locked or unlocked). If somehow the boot0 did change randomly in the future without a bootloader update then the script wouldn't run, it would abort, questioning whether this was the intended device or not since it couldn't determine the lockstate from the stored sha1sums. :good:
osm0sis said:
Hey great to finally get some more information about the encryption used and the content of boot0-1. Very interesting stuff. How did you determine this? We couldn't find much documentation on the matter. Any ideas on how to decrypt it would also be greatly appreciated, since that might allow segv11 to still be able to include it in the BootUnlocker app.
So far the only time we've seen the md5hash of the boot0 block change on a particular device is with bootloader version change, after which it continues to remains consistent depending on lockstate. I was merely guessing that was part of the encryption process but the data changing would of course also make perfect sense, so thank you for that information. What doesn't change when unlocking/locking the bootloader is boot1, so flipping between the two states for boot0 will still keep decryption of boot1 intact.
I definitely understand your concerns that it is a dangerous business writing to these blocks, and I agree, but as you've seen I haven't taken this lightly in either my posts or my script; the script has safeties built in to make sure it only writes to boot0 when it meets one of the two known states for that person's device (locked or unlocked). If somehow the boot0 did change randomly in the future without a bootloader update then the script wouldn't run, it would abort, questioning whether this was the intended device or not since it couldn't determine the lockstate from the stored md5hashes. :good:
Click to expand...
Click to collapse
it is off the shelf tegra security. As I said at this time changes shouldn't echo all the way through, but the BCT partition is usually ~3MB but only uses a fraction of that.
Decryption and Encryption of the data is not something easily available, it entirely defeats the purpose of it if you can do it yourself.
lilstevie said:
it is off the shelf tegra security. As I said at this time changes shouldn't echo all the way through, but the BCT partition is usually ~3MB but only uses a fraction of that.
Decryption and Encryption of the data is not something easily available, it entirely defeats the purpose of it if you can do it yourself.
Click to expand...
Click to collapse
Haha yeah of course it defeats the purpose, but in a way so does unlocking the bootloader with root.
Either way, thanks for the help and your Tegra knowledge.
Works perfect
Thanks a ton osm0sis. Just tested and it's flawless. Finally got rid of that unsightly unlock icon when you first boot and I still have full functionality. Locks and unlocks in an instant with the edited .zip file. Great work! :highfive:
lilstevie said:
The encryption does not change, that is static for the life of the device,
Click to expand...
Click to collapse
I am very interested in unlocking the bootloader without rooting or fastboot oem unlock my device. I'd love to find that key and be able to write an encrypted bootloader via JTAG access for example (I guess can't do otherwise to write an encrypted image as the encryption is probably done by the bootloader while uploading an image through fastboot am I right?)
I foresee 2 possibilities, but might be very wrong: 1) key hardcoded (in the BIOS for ex), I am trying to see if I can JTAG access the processor next week (theoretically frist, as my N7 arrives after 2 weeks)
2) the key is computed based on the device serial number (which I think might very well be the case) at startup (I'd guess a logical operation like an XOR on the serial maybe with a master key hardcoded or just a crypto op on the serial) in this case it might not be required to search for it in a memory dump but aska crypto guy see if with the knowledge of cyphered data, the algorithm and the serial, a key could be diversified...
If some of you guys are interested to work on that...we could open a new thread?
Meanwhile any of you know where I can get more info on the memory map of the flash?
My guess was that it was device serial number based as well. If you want to work on decrypting it, you could probably take it back to the main BootUnlocker App Dev thread: http://forum.xda-developers.com/showthread.php?t=1731993, since if you ever got it working it could likely be included in the app again.
No idea on the memory map unfortunately.
Just a reminder to everyone to unlock before you flash the OTA. Instructions for updating the script for new bootloader versions are in the 3rd post of this thread.
Happy OTA Day!
What is strange USP.img sha1 did not change. It still is 8c206a1a87599f532ce68675536f0b1546900d7a
???
---------- Post added at 06:07 PM ---------- Previous post was at 05:58 PM ----------
Anyway....working ok with 4.2.2 after updating with post 2 instructions.
sebarkh said:
What is strange USP.img sha1 did not change. It still is 8c206a1a87599f532ce68675536f0b1546900d7a
???
---------- Post added at 06:07 PM ---------- Previous post was at 05:58 PM ----------
Anyway....working ok with 4.2.2 after updating with post 2 instructions.
Click to expand...
Click to collapse
You're right, interesting! My guess, based on what lilstevie said, is that when the OTA writes the new bootloader to /USP it actually writes it to multiple contiguous partitions starting with USP, including the mmcblk0boot ones we dump. So whatever changed in the bootloader didn't alter the actual USP part this time, and that's why it checksums the same. The mmcblk0boot blocks do change, so the method in post 3 should still be followed.
Just updated to 4.18 and followed the instructions (minus the USP section in post 3) and all is working as expected. Thanks again!
Just noticed that having the mount /system in an assert will actually fail the assert if the system is already mounted. Not really a big deal, just means /system can't already be mounted when you go to run the BootUnlocker script or it won't make it past the device check. I haven't decided whether it matters enough to upload a new version of the script zip or not, since it's easy enough to go unmount /system before running it.
Also easy enough to fix it yourselves if you like:
Code:
assert(mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system"),
getprop("ro.product.device") == "grouper" ||
getprop("ro.build.product") == "grouper");
should instead be:
Code:
mount("ext4", "EMMC", "/dev/block/platform/sdhci-tegra.3/by-name/APP", "/system");
assert(getprop("ro.product.device") == "grouper" ||
getprop("ro.build.product") == "grouper");
Anyway, thought I'd give everyone the heads up even though nobody's apparently run into it or brought it to my attention before. :good:
Thanks for your tips! As I prefer to use the stock recovery I made a script to use your solution from the device itself, placing the partition backups in /system/usr/bootunlock. Here it is in case anyone else finds it useful:
Code:
#!/system/bin/sh
case $1 in
"lock")
echo "[x] Locking bootloader..."
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/system/usr/bootunlock/locked-mmcblk0boot0.img of=/dev/block/mmcblk0boot0
echo 1 > /sys/block/mmcblk0boot0/force_ro
echo "[x] Bootloader locked!"
;;
"unlock")
echo "[x] Unlocking bootloader..."
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/system/usr/bootunlock/unlocked-mmcblk0boot0.img of=/dev/block/mmcblk0boot0
echo 1 > /sys/block/mmcblk0boot0/force_ro
echo "[x] Bootloader unlocked!"
;;
*)
echo "Usage: $0 <lock|unlock>"
exit 1
;;
esac
Does it still work on the latest bootloader of Androud 4.3?
I just need to change the value in script and replace img files?
Thanks.
Intro
This is a guide for people who want to make some modifications to config files, or other files, on System partition but do not want to root their phone or install custom recovery in order to keep OTAs and some apps, which don't play nicely with rooted phones, working. Examples of those config mods could be changing DPI or changing volume levels etc, which you would only do once and forget about it.
While root allows you to do those kinds of changes from within android, this methods would require a PC.
If you are familiar with temporary booting into a custom recovery, skip to step 5.
The usual i am not responsible for any of your actions / bricked phones disclaimer applies.
Prerequisites
- A working adb / fastboot environment. Please use Android SDK, if you installed your adb and fastboot using other tools, things might not work, so please just install SDK, install Google USB Driver from SDK manager, install Platform-Tools from SDK manager (should be installed by default) and then add your sdk platform-tools path to your PATH environment variable to have it available in cmd in every path.
- Unlocked bootloader
- TWRP image for you phone (.img) https://twrp.me/devices/huaweinexus6p.html
Follow the [GUIDE] Unlock/Root/Flash for Nexus 6P for that.
Instructions
Here is an example of modifying DPI. I prefer build.prop method of modifying DPI because using the adb wm density command usually caused some issues for me, but modifying via build.prop didn't.
1 - With you phone ON, connect it to the PC and make sure adb is working by running
Code:
adb devices
and making sure that device is listed
2 - Reboot into bootloader. and make sure fastboot is good to go too. Run commands one at a time:
Code:
adb reboot bootloader
fastboot devices
3 - Place your TWRP image file in some easily accessible folder, for the sake of this example i will use C:\Mods.
4 - Temporary boot into TWRP (we are not flashing it here at all).
Code:
fastboot boot c:\Mods\twrp-2.8.7.0-angler.img
Here is where things may not work. If you don't see your phone boot into TWRP then either your adb / fastboot environment not setup correctly (installed via a tool instead of SDK) or your img file is corrupt.
One thing that works for me when TWRP refuses to boot is to restart cmd and issue the command again this closes and reopens adb/fastboot daemon.
5 - Once TWRP is up on your phone it may display a warning saying "TWRP has detected an unmounted system partition". Swipe to allow modifications at the bottom. This screen may not come up at all.
6 - Go to Mount >>> Tick System >>> Make sure "Only Mount System Read Only" is unticked >>> Press Back button
7 - Back on your PC check if your device is listed
Code:
adb devices
8 - Pull the file you need to modify from system partition to your PC. Please note the direction of the slashes:
Code:
adb pull /system/build.prop c:/Mods
9 - Now you should see build.prop in your c:\Mods folder. Use Notepad++ or something like that to edit the file. Find the line with lcd_density= and change it's value to whatever you need and save the file.
10 - Push the file back to your phone:
Code:
adb push c:/Mods/build.prop /system
11 - Reboot
Code:
adb reboot
12 - Profit.
Hope this will help anyone who is looking to do some mods without installing custom recovery and rooting your phone.
Cheers.
Would this work for adding the tethering bypass line in the build prop?
Yes it will. What's the line again I was looking for it the other day and couldn't find it...
Works are per OP's original post, tested and boosted the headphone volume without a problem.
Headphone path is /system/etc/mixer_paths.xml
So as per OP's example to pull: adb pull /system/etc/mixer_paths.xml c:/Mods
push: adb push c:/Mods/mixer_paths.xml /system/etc
I'm using the OP's "Mods" folder to demonstrate the file path but this may vary on your PC.
Can I use this to push SuperSU / etc to my device without having to permanently flash TWRP?
skrowl said:
Can I use this to push SuperSU / etc to my device without having to permanently flash TWRP?
Click to expand...
Click to collapse
You can certainly push the files to system partition and they will retain there after reboot. So if you know which files have to be pushed for SuperSU then give that a go. It shouldn't break anything.
I haven't tried pushing SuperSU files to system partition before so I can't guarantee that OTAs will work after this. The only way to find out is to try it i guess...
Can you run nandroids?
not sure if it's allowed or not.. but with this can i push hosts file onto the phone as well for ad-blocking...?????
I will say thanks now and try it later. These are the type of tweaks I would like to make to my phone. Do you know if changing the DPI cause any stock applications to show up broken like they do on the Samsung phones?
NCguy said:
Can you run nandroids?
Click to expand...
Click to collapse
Im not sure what you mean?
rohit25 said:
not sure if it's allowed or not.. but with this can i push hosts file onto the phone as well for ad-blocking...?????
Click to expand...
Click to collapse
If it's on the system partition then I yes you can.
locolbd said:
I will say thanks now and try it later. These are the type of tweaks I would like to make to my phone. Do you know if changing the DPI cause any stock applications to show up broken like they do on the Samsung phones?
Click to expand...
Click to collapse
I've never had a problem with changing DPI using this method on a nexus phone if that helps.
denk said:
Im not sure what you mean?
Click to expand...
Click to collapse
Can you run nandroids backups from TWRP by just booting into it?
okay so after i did this i get the following during boot up
"Your device is corrupt. It can't be trusted and may not work properly". Does this mean i will not get Securty Updates any more? I saw i had an update before i performed this however, now i do not see that update notifications any more.
locolbd said:
okay so after i did this i get the following during boot up
"Your device is corrupt. It can't be trusted and may not work properly". Does this mean i will not get Securty Updates any more? I saw i had an update before i performed this however, now i do not see that update notifications any more.
Click to expand...
Click to collapse
I got this too when I flashed MOAB via adb sideload. I'm just wondering if the same warning appears with the adb push method. Also, the file's permissions don't need to be set after adb push?
My main concern is if Android Pay still works with the red triangle warning. Anyone?
FYI Flashing back to stock is no issue for me.
NCguy said:
Can you run nandroids backups from TWRP by just booting into it?
Click to expand...
Click to collapse
I think if you get the latest TWRP which supports decryption of data partition (where all your stuff is) you should be able to back it up.
Edit: backup works on nexus 5 with temporary TWRP boot. Sorry I'm still waiting for my 6p to arrive.
locolbd said:
okay so after i did this i get the following during boot up
"Your device is corrupt. It can't be trusted and may not work properly". Does this mean i will not get Securty Updates any more? I saw i had an update before i performed this however, now i do not see that update notifications any more.
Click to expand...
Click to collapse
Thanks for trying it out! Sometimes OTA notifications take a little while to come up after reboot. But based on the warning Im afraid that they might be disabled now. It looks like it runs some sort of a check on the system partition to verify its legitimacy. So modifying files would be fine on it using this method but looks like adding them won't work.
TWRP just released their recovery with decryption support so you can just follow the standard procedure or just temporary booting into TWRP and rooting from there which works as well.
denk said:
I think if you get the latest TWRP which supports decryption of data partition (where all your stuff is) you should be able to back it up.
Edit: backup works on nexus 5 with temporary TWRP boot. Sorry I'm still waiting for my 6p to arrive.
Click to expand...
Click to collapse
On your Nexus5 I assume you are also unrooted? And have you tried a Nandroid restore, booted TWRP, no root?
NCguy said:
On your Nexus5 I assume you are also unrooted? And have you tried a Nandroid restore, booted TWRP, no root?
Click to expand...
Click to collapse
Just ran a restore to test it for you. Works fine as well.
My N5 is unrooted.
.
denk said:
Just ran a restore to test it for you. Works fine as well.
My N5 is unrooted.
.
Click to expand...
Click to collapse
Thanks a lot for that. I didn't unlock the bootloader. Ugh. Time to start over. To me nandroids alone make it worth the effort.
I have been experimenting with flashing, etc. and somehow the lockscreen were corrupted and the pattern I was using was not longer valid. I had the fingerprint already setup so I could enter using the rear sensor, but having a corrupted lockscreen is annoying. THis method requires TWRP custom recovery. It is compatible with locked bootloaders and doesn't modify the stock boot or system. It is also compatible with all the AAXON 7 models.
If you have the stock ROM and need TWRP and ADB interface:
A. Setup ADB interface in your PC and device drivers. and connect your terminal to the PC.
B. Setup axon7tool in your computer. Enter into EDL mode by running the command "adb reboot edl" in the command prompt. The terminal will seen to be off.
C. Disable the antivirus and then backup your recovery image using axon7tool running "axon7tool -r recovery". Save the created file in a safe place.
D. Flash tenfar's signed TWRP as a new recovery using axon7tool. It will reboot to system again.
E. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
1. In TWRP , and with the ADB interface properly installed run these the commands from your computer:
Code:
adb devices
adb shell mv /data/system/locksettings.db locksettings.db.old
adb reboot
Now the system will allow you to pass lockscreen without security. In that case you do not need to apply the rest of the steps. Should you continue experimenting issues with the lockscreen, then you should apply the full procedure. Just add the following 2 steps:
2. Open the command prompt and run:
Code:
adb devices
adb reboot recovery
3. When TWRP had fully loaded, run in the command prompt the following commands:
Code:
adb devices
adb shell mv /data/system/gatekeeper.pattern.key gatekeeper.pattern.key.old
adb shell mv /data/system/locksettings.db locksettings.db.old
adb shell mv /data/system/gatekeeper.password.key gatekeeper.password.key.old
adb shell mv /data/system/locksettings.db-shm locksettings.db-shm.old
adb shell mv /data/system/locksettings.db-wal locksettings.db-wal.old
adb reboot
If you want to restore the stock recovery, you just need to rename the recovery-backup.bin file created in step C back to recovery.bin and run the command "axon7tool -w recovery". after that you can enable your antivirus software again. axon7tool can't connect with some antivirus software. I will be editing this OP with links to the procedures required for each step. All of them are in this forums.
Enjoy
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
DrakenFX said:
@Oki
To fix either " Wrong Pattern " , " Wrong Pin " users only need to delete " /data/system/locksettings.db " from either Terminal/File Explorer with root or TWRP File explorer then Reboot and you'll be good to go .
Click to expand...
Click to collapse
Sure! but this guide is intended for people with the stock, unrooted, blocked bootloader who want to remain with a pure stock experience. Usually people without experience rooting devices. This is why I will edit the guide to add all the details to every step.
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
twilighttony said:
Could I do this with a pin as well? I restored a backup and it corrupted my password and I have to use the fingerprint on the back to get in.
Click to expand...
Click to collapse
Yes, the procedure deletes everything. If you have problems just do the same also with:
gatekeeper.password.key
locksettings.db-shm
locksettings.db-wal
I have updated the OP just to describe the full procedure.
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.
I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.
Of course, I am rooted with twrp, so this comes after setting that up.
Masterjuggler said:
I had this problem earlier today of having the PIN corrupted, but I have it set to require the pin on the first boot.
I fixed it by removing all files ending in ".key" in /system. Not really sure how this compares to removing locksettings.db. Afterward, I put my password back using Google's device manager.
Of course, I am rooted with twrp, so this comes after setting that up.
Click to expand...
Click to collapse
The problem of this method is that it only works if the bootloader is unlocked and the phone has the No-verify patch installed.
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.
So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
Masterjuggler said:
When you say "No-verify patch," are you talking about removing Google license verification from apps (via an app such as lucky-patcher for instance)? AFAIK that is on a per-app basis and wouldn't affect something like the lockscreen password.
So if the phone has those prerequisites (unlocked, No-verify, TWRP), is there a difference between removing the ".key" files and the locksettings.db? I am not entirely sure what the different files contain, and don't seem to be able to find this information through Google, though I may just not be searching the right set of keywords.
Click to expand...
Click to collapse
No-Verify is an additional security system implementend in the kernel. When No-Verify is active, it checks for the signature of the system partition. If the system was modified, then the system won't boot. This is why after unlocking the bootloader you have to apply No-Verify Patch or any package with the integrated patch such as SuperSU. As you can see, it has nothing to do with the app signature or the lockscreen at all.
The method presented in the OP is valid for most Android phones, and the only prerequisite is to have TWRP installed. It is safe and a lot more recommended than patching the system partition. Patching system or kernel should always be your last resort. usually deleting locksettings.db is enough, and it is a general method that works for almost any locking method.
On B25 and have followed all instructions. Seems this method no longer works :/
None of this is my work and all recognition goes to the awesome developers that made this possible, I will link their guides in here with some minor notes for newbies like me that may had some issues trying to unlock and root the Fire Stick (FS) 4K
DISCLAIMER: BE WARNED THAT YOU HAVE TO OPEN YOUR FIRE STICK AND IT WILL VOID YOUR WARRANTY, THIS IS NOT FOR THE FAINT OF HEART AND NEITHER THE DEVELOPERS OR MYSELF ARE RESPONSIBLE IF YOU BRICK YOUR DEVICE OR VOID YOUR WARRANTY
Ok, now let's begin:
UPDATE: Per Sus_i, this makes perfect sense:
"Since the exploit can't be patched, it's in my opinion the best to do the setup at the beginning, pair the remote, then update to the latest over fireOS. That way you avoid a pending update nag setup screen after doing the exploit. Then enable ADB and unknown sources. After kamakiri I would flash only magisk.zip + sideload the manager app with adb... and avoid any prerooted rom flashing until there is an update to a somewhat higher version (and the current 6.2.6.8v1 has that contact manufacturer error screen)."
First very important, I wish I would have known this before but make sure you have a Laptop and a Monitor to Connect the FS to, so basically the USB Power cable from the FS connect it to your laptop and connect the HDMI portion to a monitor or TV
I also strongly recommend to have your FS deregistered before continuing as this will prevent your FS from automatically updating after rooting
In order to unlock the bootloader follow "THIS GUIDE"
I made a quick video on how to open your device and how to Short it using Aluminum Foil:
https://www.youtube.com/watch?v=h4I6ifBLWJ4
Process is pretty self explanitory, make a USB ISO from the image provided on that thread, boot into it and open terminal, make sure you put the file he provides on a RW location, my mistake was that I put it inside a RO folder and it would not load the script, so I mounted the kamakiri-mantis-v1.2.zip unto the /mnt directory of the usb and I was able to run the script successfully, make sure to run the commands quickly as the first time that I it finished the ./bootrom-step.sh script and I left it sitting for 10 minutes to grab a bite, I couldn't run the second script and had to start all over. After the second ./fastboot-step.sh script, your device will be on the TWRP recovery, now on the same terminal page or a new one enter these commands:
Code:
adb devices
adb shell
exit
You should see your device's serial number from the first command with "device" to the right of it and the second command will basically put you inside the device's directory assuming you have established a successful connection. The last command just put you back to your starting point, now open the firefox browser on the FireOS USB and navigate to the URL below
Download the Pre-Rooted Image from "HERE" This image contains Magisk already so you don't have to worry about installing it separately, the image is larger than the available partition on this USB so this is a good time to either get a second USB or if you want to download the file to your local hdd and pull them from there its up to you, then run these commands:
Code:
adb push <your download location you decided earlier here>/mantis-6.2.6.8-rooted_r1.zip / sdcard/
adb reboot recovery
adb shell
twrp install /sdcard/mantis-6.2.6.8-rooted_r1.zip
twrp wipe cache
twrp wipe dalvik
reboot -p
This basically installs the pre-rooted image to your device, after the last command, you should see on your monitor the Fire Stick Reboot and boot to the Amazon GUI Splash Screen, now very important if you followed my previous instructions of deregistering your device before performing all these steps, it should bring you up to the Amazon Initial Setup Screen, now what you want to do is do the following commands before continuing on terminal:
Code:
adb devices *you should see something your screen where the FS is connected to, click accept or enter can't remember*
Now it should show you in terminal your serial number and "device" next to it, meaning you can run adb commands in which you will run the following to disable OTA updates:
Code:
adb shell
su *after this command you should see something again on your screen, click the check the box "Always Remember" and click ok" *
if "su" was successful, you should see something like this:
mantis:/ $ su
mantis:/ # *the hash means you're running as root, if you don't have a "#" you are not running as root"
Than continue with these commands and should get the following results:
pm disable com.amazon.tv.forcedotaupdater.v2
***Package com.amazon.tv.forcedotaupdater.v2 new state: disabled***
pm disable com.amazon.device.software.ota
***Package om.amazon.device.software.ota new state: disabled***
pm disable com.amazon.device.software.ota.override
***Package com.amazon.device.software.ota.override new state: disabled***
After running all these commands exit adb and continue with the normal Amazon Setup including adding your amazon account. After you get to the screen where you can see all the apps, open a new web page browser in firefox and download "This Add-On" , this one is less than 200MB so it should fit on the Fire OS USB, so I would download it and copy it to /mnt for ease of access, go back to terminal and type this:
Code:
adb devices
adb push <your download location you decided earlier here>/AFTV-MM-1.7-6.2.6.8.zip/ sdcard/
adb reboot recovery *it will boot into TWRP*
adb shell
twrp install /sdcard/AFTV-MM-1.7-6.2.6.8.zip
twrp wipe cache
twrp wipe dalvik
reboot -p
Your device will reboot and if everything went smoothly, you should have a rooted amazon fire stick 4k, Congrats :good:
Nice guide
Here are a few thoughts from me...
It's important to use the latest kamakiri. The mentioned prerooted 6.2.6.5 is probably a downgrade. A few sticks needs an update of the TZ in order to play prime video. The TZ update is only in the v1.2 Kamakiri or in the 6.2.6.6 prerooted.
Edit: S̵i̵n̵c̵e̵ ̵t̵h̵e̵ ̵e̵x̵p̵l̵o̵i̵t̵ ̵c̵a̵n̵'̵t̵ ̵b̵e̵ ̵p̵a̵t̵c̵h̵e̵d̵,̵ ̵i̵t̵'̵s̵ ̵i̵n̵ ̵m̵y̵ ̵o̵p̵i̵n̵i̵o̵n̵ ̵t̵h̵e̵ ̵b̵e̵s̵t̵ ̵t̵o̵ ̵d̵o̵ ̵t̵h̵e̵ ̵s̵e̵t̵u̵p̵ ̵a̵t̵ ̵t̵h̵e̵ ̵b̵e̵g̵i̵n̵n̵i̵n̵g̵,̵ ̵p̵a̵i̵r̵ ̵t̵h̵e̵ ̵r̵e̵m̵o̵t̵e̵,̵ ̵t̵h̵e̵n̵ ̵u̵p̵d̵a̵t̵e̵ ̵t̵o̵ ̵t̵h̵e̵ ̵l̵a̵t̵e̵s̵t̵ ̵o̵v̵e̵r̵ ̵f̵i̵r̵e̵O̵S̵.̵ ̵T̵h̵a̵t̵ ̵w̵a̵y̵ ̵y̵o̵u̵ ̵a̵v̵o̵i̵d̵ ̵a̵ ̵p̵e̵n̵d̵i̵n̵g̵ ̵u̵p̵d̵a̵t̵e̵ ̵n̵a̵g̵ ̵s̵e̵t̵u̵p̵ ̵s̵c̵r̵e̵e̵n̵ ̵a̵f̵t̵e̵r̵ ̵d̵o̵i̵n̵g̵ ̵t̵h̵e̵ ̵e̵x̵p̵l̵o̵i̵t̵.̵ ̵T̵h̵e̵n̵ ̵e̵n̵a̵b̵l̵e̵ ̵A̵D̵B̵ ̵a̵n̵d̵ ̵u̵n̵k̵n̵o̵w̵n̵ ̵s̵o̵u̵r̵c̵e̵s̵.̵ ̵ After kamakiri I would flash only magisk.zip + sideload the manager app with adb... and avoid any prerooted rom flashing until there is an update to a somewhat higher version (and the current 6.2.6.8v1 has that contact manufacturer error screen).
Edit: Update: meanwhile, the fix for the mentioned 'contact manufacturer' error is known...
Take a look here and here.
Edit/Update: Due to efuses (blocking the bootrom access), it isn't recommended to do any update infront of the unlock...
Sus_i said:
Nice guide
Here are a few thoughts from me...
It's important to use the latest kamakiri. The mentioned prerooted 6.2.6.5 is probably a downgrade. A few sticks needs an update of the TZ in order to play prime video. The TZ update is only in the v1.2 Kamakiri or in the 6.2.6.6 prerooted.
Since the exploit can't be patched, it's in my opinion the best to do the setup at the beginning, pair the remote, then update to the latest over fireOS. That way you avoid a pending update nag setup screen after doing the exploit. Then enable ADB and unknown sources. After kamakiri I would flash only magisk.zip + sideload the manager app with adb... and avoid any prerooted rom flashing until there is an update to a somewhat higher version (and the current 6.2.6.8v1 has that contact manufacturer error screen).
Click to expand...
Click to collapse
Ops Typo let me edit it, I meant to put 6.2.6.8 on the command lol, and aaaa I see I didn't know the exploit couldn't be patched great info, so than yes I will revise my instructions thank so much
UPDATE: I just checked my FS and I'm on 6.2.6.8v1 and didn't receive contact the manufacturer, is it because I sideloaded the manager app after?
nandroidint said:
UPDATE: I just checked my FS and I'm on 6.2.6.8v1 and didn't receive contact the manufacturer, is it because I sideloaded the manager app after?
Click to expand...
Click to collapse
No. If I remember correct, it has something to do with flashing, i.e. the vendor partition wasn't flashed propperly.
Maybe you flashed not the prerooted!? With the Kamakiri TWRP version is flashing full ota update packages (renamed to zip) also possible... and in the prerooted thread is such a full 6.2.6.8 ota linked.
Edit: Could be that this error is prime video related, idk. rbox said he looks into it soon...
Just for clarification: The prerooted rom is a perfect thing since years.
My suggestion 'avoid any rom flashing' from my last post is just an attempt to keep it simple for beginners.
By the way, if the stick gets all updates in front of the unlock, it makes no sense to update it after the unlock again (unless addon.d support is needed).
I hope that has become clear I very much appreciate all the prerooted stuff
thanx for the tut nandroidint this is exactly what I needed, I wasn't sure how to do the shorting so the video helped out a lot now I'm ready to do this. But I'm sorta a noob when it comes to android so I got few questions tho, 1) what are the main benefits in rooting the fIrestick 4K 2) are there different roms to install? 3) are there root only .apks? 4)also one main thing I would like to be able to do is spoofing the Mac address any idea if that's possible?
5)Oh and lastly what OTB cable do you recommend? sorry for all the questions ?
'std::bad_alloc'
After running the adb push of the manthis.zip Im getting terminate called after throwing an instance of 'std::bad_alloc'.... What Im I doing wrong?
i gave root can i remove amazon services
i dont want google launcher jsut remove services
Sooo there’s no way to expand the storage? Even after rooted? Just bought an otg cable ?
Can I please get some support guys ? previous questions I don’t need answered I found someone on twitter who explained a few things but can someone please answer this.
Hello, after root i got massage on screen
: android system
There is na internal problem with Your device. Contact Your manufacturer for detalis.
And when im trying to register in Amazon it bringing me back to pairing screen, farest i can go it is wifi connection.
Did i brick my Stick?
davinci2798 said:
Hello, after root i got massage on screen
: android system
There is na internal problem with Your device. Contact Your manufacturer for detalis.
And when im trying to register in Amazon it bringing me back to pairing screen, farest i can go it is wifi connection.
Did i brick my Stick?
Click to expand...
Click to collapse
Did you deregister before rooting like the tut says? This is why I’ve been hesitant on rooting because of the lack of support on this forum
Yep, it was new Stick, out from box. Not registered at all. I managed massage, but still comminng to pairing screen.
itsyaboy said:
Sooo there’s no way to expand the storage? Even after rooted? Just bought an otg cable
Can I please get some support guys previous questions I don’t need answered I found someone on twitter who explained a few things but can someone please answer this.
Click to expand...
Click to collapse
You can use adoptable storage on 4K stick with Add-Ons installed and activated AFTV-XM Xposed Module. It brings adoptable storage support to Settings UI.
tsynik said:
You can use adoptable storage on 4K stick with Add-Ons installed and activated AFTV-XM Xposed Module. It brings adoptable storage support to Settings UI.
Click to expand...
Click to collapse
Nice! That’s awesome thanx for the info and reply.
davinci2798 said:
Yep, it was new Stick, out from box. Not registered at all. I managed massage, but still comminng to pairing screen.
Click to expand...
Click to collapse
Hey so have you figured out what was the problem yet? If so could u explain how you managed to fix it? I’m going to root sometime this week and would hate to run into this issue.
USB drive for storage
itsyaboy said:
Sooo there’s no way to expand the storage? Even after rooted? Just bought an otg cable
Can I please get some support guys previous questions I don’t need answered I found someone on twitter who explained a few things but can someone please answer this.
Click to expand...
Click to collapse
Yes, You can use a USB drive for App loading and Movie storage.
See Troypoint.com for good video.
I suggest a single USB OTG Cable and a USB HUB for your drive.
Then you can add a Keyboard and Mouse which make it MUCH easier to type commands.
Good Luck
How might one do this on a Mac?
Thanks
gogorman said:
How might one do this on a Mac?
Thanks
Click to expand...
Click to collapse
Do what? The only thing u can do on the MacOS is to create the bootable iso usb, you can follow these steps to do so https://www.google.com/amp/s/www.le...-on-an-apple-mac-os-x-from-an-iso?hs_amp=true
After your create the bootable usb just reboot and hold down option and select the bootable usb, once in open up Firefox and download the kamakiri-mantis-v1 and open a terminal window and change the directory to where u have the kamakiri folder, in terminal type cd then just drop in the kamakiri and hit enter. From there u can just follow the tut, FYI the bootable usb you create is a Linux OS so that’s how you can do it on a Mac, you just can’t do the rooting on MacOS, just clarifying Incase that was your question.
Sorry I haven't rooted phones in a while and am trying to root my fire stick 4k. Can we get some pictures tutorial pretty please
Sent from my ONEPLUS A5010 using Tapatalk
Step by step instructions would be great?
chinkster said:
Sorry I haven't rooted phones in a while and am trying to root my fire stick 4k. Can we get some pictures tutorial pretty please
Sent from my ONEPLUS A5010 using Tapatalk
Click to expand...
Click to collapse
I would love that too, I have rooted with Unix before but that was on a Drone(Solo).
I understand about creating a bootable USB drive and booting my PC/Mac by changing the bios to boot first off the USB as step 1.
Step 2 is loading software onto the USB while booted under Unix/Linux???
Step 3 How do you then connect to the firestick?
When do you plug the firestick into the tv and when do you short out the jumper??
I know to some of you these sound very basic but it would be helpful for those of us just learning this environment.
Thanks in advance...
RPM99 said:
I would love that too, I have rooted with Unix before but that was on a Drone(Solo).
I understand about creating a bootable USB drive and booting my PC/Mac by changing the bios to boot first off the USB as step 1.
Step 2 is loading software onto the USB while booted under Unix/Linux???
Step 3 How do you then connect to the firestick?
When do you plug the firestick into the tv and when do you short out the jumper??
I know to some of you these sound very basic but it would be helpful for those of us just learning this environment.
Thanks in advance...
Click to expand...
Click to collapse
The link he provided explains all that https://forum.xda-developers.com/fire-tv/orig-development/unlock-fire-tv-stick-4k-mantis-t3978459 all except for when to connect to the tv, but I assume it’s after running the kamakiri script, btw it’s not software, you just download the kamakiri mantis while in the Linux usb os, open a terminal and change the directory of the terminal to the kamakiri folder in order to run the ./bootrom-step.sh and ./fastboot-step.sh commands
Edit: just follow the main guide from the link above then read this guide after, that’s the best way to understand it.