Database Develop

Frequently Asked Questions - 2nd Generation Kindle Fires

[SIZE=+3]Frequently Asked Questions[/SIZE]
[SIZE=+2]2nd generation Kindle Fires[/SIZE]​
[SIZE=+1]This a short list of frequently asked questions in this device forum and the answers often given as a response. It should serve as a starting point for gathering knowledge and finding solutions to many common problems. Please only post in this thread with feedback on how to improve this document. Do not post "Thank you" type responses. If you have additional questions or require more help, try to find an existing thread or create your own. Do not use this as a general help thread.[/SIZE]
[SIZE=+1]Q1: How can I tell if I have a 2nd generation Kindle Fire?[/SIZE]For HD models the answer should be pretty obvious, but the KF2 has nearly the exact same hardware configuration as the original. Short of opening the device, the only way to tell for sure is by checking the software version. Devices running a software version of 6.3.2 or earlier is a 1st generation Kindle Fire. All other versions belong to 2nd generation Kindle Fires.​[SIZE=+1]Q2: What is the most important thing to know about the 2nd generation Kindle Fires?[/SIZE]The 2nd generation Kindle Fires are running on OMAP4 HS processors with “M-Shield” turned on. What that means is ANY alteration to certain partition images containing digitally signed headers (with one exception) will result in the OMAP ROM halting the boot process and the resulting “brick” will be irreparable by anyone but Amazon. For more information, or just for an interesting read, go here: New Kindle Fires are locked​[SIZE=+1]Q3: What partition images contain these signed headers?[/SIZE]The xloader, bootloader, recovery, and boot (kernel) partition images all have signed headers. Any attempt at installing custom versions of these partition images by means of traditional methods to modify the device will result in the aforementioned irreparable “brick”.​[SIZE=+1]Q4: How do I create a partition image with a signed header that can be used on the 2nd generation Kindle Fires?[/SIZE]You can't. Ignoring the fact that the signed header must have the exact same 64Kb signature that Amazon uses in the factory, the software used to produce this signature is not available to the general public, but only to “high volume wireless OEMs and ODMs”.​[SIZE=+1]Q5: You mentioned “one exception” to installing custom partition images? Could you elaborate on this?[/SIZE]While the “M-Shield” technology for OMAP HS processors is pretty robust, the same ccouldn't necessarily be said for Amazon's software. The stock Kindle Fire bootloaders from software updates previous to 8.3.0 (KFHD8.9), 7.3.0 (KFHD7), and 10.3.0 (KF2) have an exploitable hole in the boot process which allows the installation of a 2nd bootloader (on the system partition) and unsigned custom recovery & boot (kernel) images, without much fear of doing irreparable harm, but the actual bootloader must still remain stock. It should be noted that stock Kindle Fire bootloaders since the 8.3.0 (KFHD8.9), 7.3.0 (KFHD7), and 10.3.0 (KF2) updates have this hole patched and any attempt to install the 2nd bootloader along with unsigned recovery & boot images WILL BRICK THE DEVICE.​[SIZE=+1]Q6: How will I know what version of the stock bootloader is installed on my device?[/SIZE]There is no way to confirm with all certainty what bootloader version is installed on the device, but a very good indicator to look for is the software version itself. Software versions prior to 8.1.4 (KFHD8.9), 7.2.3 (KFHD7), and 10.2.4 (KF2) have bootloaders that can be exploited. Everything beyond that must be replaced with one from a previous software update version. ​[SIZE=+1]Q7: My device is running a software version with a stock bootloader that cannot be exploited (or I am not sure). How can I install the 2nd bootloader for running custom ROMs and recovery?[/SIZE]Use fastboot to flash a signed stock bootloader from a previous software version. It should be noted that this is very risky to do. Sudden losses or surges of power, accidental unplugging of the USB cable, or flashing a bad download can potentially brick the device, for good. Always check md5s on all bootloader downloads, make sure you have a good charge, and keep all small children at a respectable distance. ​[SIZE=+1]Q8: Where can I find the 2nd bootloader and information on how to install it?[/SIZE]
[BOOTLOADER] Install 2nd-bootloader for Custom ROMs on KFireHD 8.9”
[BOOTLOADER] Install 2nd-bootloader for Custom ROMs on KFireHD 7"
[BOOTLOADER] 2nd-Bootloader/Recovery unlock process for KFire 2
[SIZE=+1]Q9: What can I do to restore my device if the 2nd bootloader and custom recovery is not installed?[/SIZE]Use fastboot to restore saved partition images from or for your particular device.​[SIZE=+1]Q10: How do I save my partition images to restore later if needed?[/SIZE]For HD models, there is a script created by kinfauns that will do the work for you, but it will not work properly for the KF2 if the partition layout isn't the same. Regardless of what device you own, this can easily be done on any rooted device using 'dd' to save those partitions to the sdcard, then transfer them to your computer:
Code:
adb shell su -c “dd if=/dev/block/mmcblk0pX of=/sdcard/<filename>.img”
...where 'X' will be a number 1-13 (depending on partition layout) and '<filename>' will be the name of that partition. You can get a list of partition names and corresponding numbers with the following command:
Code:
adb shell su -c “ls -l /dev/block/platform/omap/omap_hsmmc.1/by-name
Use 'adb pull...' to transfer the images to your computer for safe keeping, and avoid trying to save the userdata or sdcard partitions.​[SIZE=+1]Q11: How do I restore a saved partition in fastboot?[/SIZE]
Code:
fastboot -i 0x1949 flash <partition_name> <partition_name>.img
...where '<partition_name>.img' should be the full path to the appropriately named partition image located on your computer. ​[SIZE=+1]Q12: Where can I get saved partition images for my device if I haven't previously saved them myself?[/SIZE]
[BACKUP][RECOVERY] Kindle Fire HD and 2 First Aide Software
[SIZE=+1]Q13: How do I restore my device if the 2nd bootloader and custom recovery is installed?[/SIZE]Generally speaking, most any problem can be resolved by reinstalling a ROM while being sure to wipe data (factory reset) first.​[SIZE=+1]Q14: How will I know if I have a bricked 2nd generation Kindle Fire that cannot be restored?[/SIZE]The device will not show any outward signs of life; no display, no sound, and no LED. The device may still get warm when plugged in or turned on and Windows users may see an OMAP4 device in the device manager. Again, short of sending it back to Amazon, there isn't anything that can be done. ​[SIZE=+1]Q15: What about the 'usbboot' method used on 1st generation Kindle Fires for replacing a malfunctioning bootloader? Could something similar be implemented for 2nd generation Kindle Fires?[/SIZE]Not likely. The 'usbboot' method used to install the xloader, bootloader, and custom recovery on the 1st generation Kindle Fires is different for 2nd generation devices. The most significant difference being the USB loader used to initially flash these images must also have a digitally signed header. As explained by Pokey9000, short of finding an exploit in the OMAP ROM code (unlikely) or somehow acquiring the appropriately signed USB boot tools used by Amazon to flash the bootloader in the factory (even less likely) it will probably never work.​[SIZE=+1]Q16: How will I know if my 2nd generation Kindle Fire can be restored?[/SIZE]Generally speaking, any device that will power on and show at least something on the display, will give you access to fastboot, thus the ability to restore saved partition images, and in effect the device. Many times this will require the use of a factory cable, so in some cases, owners of the KFHD8.9 will be out of luck.​[SIZE=+1]Q17: How can I access fastboot mode on 2nd generation Kindle Fires?[/SIZE]There are 3 methods currently used for accessing fastboot mode on the 2nd generation Kindle Fires. Depending on the model, one or more of these methods may not work.
For all devices, entering “reboot bootloader” in the shell as the root user should reboot the device into fastboot mode.
On HD models, entering a fastboot command that waits for a handshake from the device (i.e. <waiting for device>”) such as “fastboot -i 0x1949 getvar product” and rebooting the device will usually enable fastboot mode when the device reboots.
On the KFHD7 and KF2, a factory cable can be used to access fastboot mode by plugging it into the device after it has been powered down.
[SIZE=+1]Q18: My device, when booted, displays a red or orange screen and does not respond to fastboot commands. What happened?[/SIZE]You probably tried to install the 2nd bootloader and custom recovery without making sure the bootloader you're running is the the unpatched version from a previous update. The red screen, or “Wall of Fire” as Amazon calls it, is displayed when the digital signatures don't match, as would be the case when installing custom recovery on a device with a patched bootloader. A factory cable is needed to get into fastboot so those partitions can be restored to the original signed versions. Since the factory cable doesn't work on the KFHD8.9, owners of these devices may be out of luck. ​[SIZE=+1]Q19: What is a factory cable? What is it used for? How do I use it?[/SIZE]A factory cable, not to be confused with the OEM USB cable that comes with the Kindle Fire, is a USB cable made to emulate a Motorola factory programming cable. With the some devices, it is an easy way to access fastboot mode, especially when no other options are available. To use it, while plugged into your computer, simply plug it into a your device once it has been powered down.​[SIZE=+1]Q20: Where can I find information on making or purchasing a factory cable?[/SIZE]
[Info]Making/Using a Factory Cable
SkOrPn
[SIZE=+1]Q21: How will I know when my device is in fastboot mode?[/SIZE]It will say “Fastboot” on the display​[SIZE=+1]Q22: I have access to fastboot mode, but fastboot commands won't work (prompt sits at <waiting for device>). What's wrong?[/SIZE]Your USB/device drivers aren't configured properly.​[SIZE=+1]Q23: Where can I find information on how to properly install the drivers?[/SIZE]
[GUIDE] Kindle Fire For Beginners – Post #2
Let's take some of the mystery out of getting ADB working in Windows
Note: While those tutorials are made for the original Kindle Fires in mind, the information is still the same in regards to installing and configuring USB device drivers.​[SIZE=+1]Q24: I've read all the tutorials and tried various different tools, but I'm still unable to get my drivers working properly. What else can I try?[/SIZE]
SoupKit
[SIZE=+1]Q25: Now that I know all of the important stuff, how do I root my 2nd generation Kindle Fire?[/SIZE]While there are several tools and scripts used to root the 2nd generation Kindle Fires, they all rely on the same basic method, the Bin4ry method , which takes advantage of a remount timing issue during an ADB restore. It is very effective and works for nearly all devices natively running Ice Cream Sandwich.
Note: Despite some of the rumors about using your Amazon account password as the encryption password, this is a misconception. No password is needed because none was set.​[SIZE=+1]Q26: Where can I find information about how to install Google Play on the stock OS?[/SIZE]
[ROOT][HOW TO] Install Google Play Store Noob (Simple) Version
[SIZE=+1]Q27: Where can I find information about how to install Google Apps on the stock OS?[/SIZE]
[ROOT][HOW TO] Install Google Apps with Speech Recognition Noob (Simple) Version
*​Forum Rules | New Users Guide | XDA Tour | Report Posts​This FAQ is part of a Recognized Contributor Group Initiative. Please look for a similar FAQ thread when visiting another device forum.​

Excellent idea! Please sticky. :thumbup:
This is a Kinology HD using XDA Premium

What's funny to me is that people still get confused that their KF2 are NOT the same as a KFHD7.
It is understandable, of course, because they look the same on the outside and to a general consumer who lacks the knowledge of software can easily confuse the two, however, it must be made clear in some way, or otherwise we get more cases where people with a KF2 flashes a KFHD7 bootloader and such.
However, if you're going to venture so far as to void your warranty and get yourself involved with things like ADB, Fastboot, and Bootloaders where warnings and BIG bold RED letters , you should first know what model you have and what types of posts are designed for your device. Not to be mean, just saying. It would save you a ton of time and trouble, and not have a paperweight on your hands. Know what you're doing, and what you're getting yourself into, and you'll be just fine.

Super useful information, Thank you Soupmagnet. :good:
Too bad the Thanks button can only be pressed once!
+1

NY K2nd Ed is running very slowly. I clear the browser, but that doesn't help at all. Any suggestions?

It should be noted that stock Kindle Fire bootloaders since the 8.3.0 (KFHD8.9), 7.3.0 (KFHD7), and 10.3.0 (KF2) updates have this hole patched and any attempt to install the 2nd bootloader along with unsigned recovery & boot images WILL BRICK THE DEVICE.
Click to expand...
Click to collapse
So does that mean all bets are off ? Any 7" KFHD that has been updated to 7.5.1 will remain a useless stock device?

Any help with a bricked HD 7? It's stuck at fire logo. Can't find anything good. It's all outdated posts/articles by like 6 years

Idea on Rooting devices with BL newer than 12940

Dear all,
this is my first post in this forum and I have done lots of reading concerning the chromecast hack and recoveries. I recently bought a device with Bootoader version 12940 which means it is not hackable. I also do not have the means to open the device and add wires to the UART. But when browsing through the different flashing/updating and recovery threads an idea came into my mind on how the bootloader security could be omitted:
I got the following facts (please correct if wrong):
- The Marvell ROM code verifies the bootloader binarys signature before executing it ( see http://blog.gtvhacker.com/2013/google-tv-or-how-i-learned-to-stop-worrying-and-exploit-secure-boot/ )
=> This means that the vulnerable original bootloader version 12840 must have a valid signature
This is my assumption:
- When the system is powered on and the NAND flash is kept in reset the SoC should try to boot from an alternate source (e.g. uart or usb).
=> This might be a way to boot the properly signed vulnerable older bootloader
There seems to be some mechanism to boot from USB if the system does not find any firmware image ( http://forum.xda-developers.com/showthread.php?t=2438715)
Idea:
=> Has already someone plugged the chromecast via USB to an PC and powered it on with the NAND disabled? It would be interesting if the device identifies itself on the USB bus (the recent Freescale and TI controllers I know do exactly this) and awaits a (most probably signed) firmware image (which we already should have with the old bootloader) or if someone found the datasheets of this SoC it might be possible to alter the bootstrap pins of the SoC to get it booting from another source
Edit: Typo

I am thinking that if there is a weakness to exploit as far as rooting, it might be found in one of the Developer enabled units faster than one of the consumer devices....
Perhaps not as the Dev Mode may only remove the Whitelist but it's worth a shot...
I have noticed that the ROM Updates seem to have slowed down a bit since Xmas...
I bet most folks would be happy enough if we just found some way of bypassing the Whitelist if we can't get full root.

probutus said:
Dear all,
this is my first post in this forum and I have done lots of reading concerning the chromecast hack and recoveries. I recently bought a device with Bootoader version 12940 which means it is not hackable. I also do not have the means to open the device and add wires to the UART. But when browsing through the different flashing/updating and recovery threads an idea came into my mind on how the bootloader security could be omitted:
I got the following facts (please correct if wrong):
- The Marvell ROM code verifies the bootloader binarys signature before executing it ( see http://blog.gtvhacker.com/2013/google-tv-or-how-i-learned-to-stop-worrying-and-exploit-secure-boot/ )
=> This means that the vulnerable original bootloader version 12840 must have a valid signature
This is my assumption:
- When the system is powered on and the NAND flash is kept in reset the SoC should try to boot from an alternate source (e.g. uart or usb).
=> This might be a way to boot the properly signed vulnerable older bootloader
There seems to be some mechanism to boot from USB if the system does not find any firmware image ( http://forum.xda-developers.com/showthread.php?t=2438715)
Idea:
=> Has already someone plugged the chromecast via USB to an PC and powered it on with the NAND disabled? It would be interesting if the device identifies itself on the USB bus (the recent Freescale and TI controllers I know do exactly this) and awaits a (most probably signed) firmware image (which we already should have with the old bootloader) or if someone found the datasheets of this SoC it might be possible to alter the bootstrap pins of the SoC to get it booting from another source
Click to expand...
Click to collapse
Good idea. I can chainload these bootloaders if I could get a dump of the vulnerable one.
There are two ways of disabling the NAND. One is to bridge a jumper (34 if memory serves me right) and the other is to just pull the disable pin high.

jchillerup said:
Good idea. I can chainload these bootloaders if I could get a dump of the vulnerable one.
There are two ways of disabling the NAND. One is to bridge a jumper (34 if memory serves me right) and the other is to just pull the disable pin high.
Click to expand...
Click to collapse
I have a partition dump of the exploitable bootloader if it helps. (which is just the bootloader written 8x times in a row, because google logic) Shoot me a PM if you need anything.

A raw dump would be best. I am considering searching for a vulnerable untouched CC and seeing what I can do with it with some hardware hackery. First things first is finding out is the nand is encrypted with a per device key, or is certain sections are encrypted, or if it isn't encrypted at all.

ddggttff3 said:
I have a partition dump of the exploitable bootloader if it helps. (which is just the bootloader written 8x times in a row, because google logic) Shoot me a PM if you need anything.
Click to expand...
Click to collapse
That would be really helpful! I'd appreciate that. I'm in #[email protected] like you, we can discuss further there.

ddggttff3 said:
I have a partition dump of the exploitable bootloader if it helps. (which is just the bootloader written 8x times in a row, because google logic) Shoot me a PM if you need anything.
Click to expand...
Click to collapse
I would be interested aswell:
probutus<at>yahoo.de Thanks!
By the way: Has anyone found a datasheet of the Armada 1500-mini CPU? Marvell seems to be rather restrictive...
It could help to find out about potential CPU bootmode options and alternatives

probutus said:
By the way: Has anyone found a datasheet of the Armada 1500-mini CPU? Marvell seems to be rather restrictive...
It could help to find out about potential CPU bootmode options and alternatives
Click to expand...
Click to collapse
I dug around a while back while looking for spec-ed operating temperature but I couldn't find anything substantial.
Seems like you have to register with Marvell or have an existing relationship to get that level of documentation.

do u think the noot version can be rooted ?
hello im wondering before buying this key if there will be probably a root ability in the near future ? or at least a way to use my own local vidéo with a non rooted one?
thanks by advance

yoann54 said:
hello im wondering before buying this key if there will be probably a root ability in the near future ?
Click to expand...
Click to collapse
Nobody knows the future.
yoann54 said:
or at least a way to use my own local vidéo with a non rooted one?
Click to expand...
Click to collapse
Avia, RealPlayer cloud and Plex. This is covered in the sticky FAQ.
Sent from a device with no keyboard. Please forgive typos, they may not be my own.

yoann54 said:
hello im wondering before buying this key if there will be probably a root ability in the near future ? or at least a way to use my own local vidéo with a non rooted one?
thanks by advance
Click to expand...
Click to collapse
The Idea is that if we can put the Marvell-CPU into usb or serial bootmode we could boot the vulnerable but properly signed original bootloader to just "recycle" the exploit. For this, I would need the cpu documentation. Till now, I didnt find anything usable

probutus said:
The Idea is that if we can put the Marvell-CPU into usb or serial bootmode we could boot the vulnerable but properly signed original bootloader to just "recycle" the exploit. For this, I would need the cpu documentation. Till now, I didnt find anything usable
Click to expand...
Click to collapse
Thanks for ur answers.....just a last question : this method here : http://gtvhacker.com/index.php/Google_Chromecast is it only for non updated chromecast devices ?

yoann54 said:
Thanks for ur answers.....just a last question : this method here : http://gtvhacker.com/index.php/Google_Chromecast is it only for non updated chromecast devices ?
Click to expand...
Click to collapse
Yes, that only works with the original (build 12072) vulnerable bootloader.
FlashCast uses the same vulnerability.

bhiga said:
Yes, that only works with the original (build 12072) vulnerable bootloader.
FlashCast uses the same vulnerability.
Click to expand...
Click to collapse
I'm starting to wonder if it isn't possible to trick the CCast by creating a fake Google services and tricking it into loading the original vulnerable version by telling it to load it as an OTA...
I suppose the biggest hurdle is finding a file of the vulnerable version that is OTA installable since the Original was never an OTAed version to begin with.

Asphyx said:
I'm starting to wonder if it isn't possible to trick the CCast by creating a fake Google services and tricking it into loading the original vulnerable version by telling it to load it as an OTA...
I suppose the biggest hurdle is finding a file of the vulnerable version that is OTA installable since the Original was never an OTAed version to begin with.
Click to expand...
Click to collapse
Google is one step ahead. Every OTA checks against the build.prop file build date (which is stored in the kernels initramfs) so you can't use old official OTA's to downgrade

ddggttff3 said:
Google is one step ahead. Every OTA checks against the build.prop file build date (which is stored in the kernels initramfs) so you can't use old official OTA's to downgrade
Click to expand...
Click to collapse
Yeah makes sense they would do some sort of version checking.

A few things on knox / rooting and bootloaders that need more testing / development

I never had the time (and the devices) to properly research this but there are a few things that other people might want to test (or already know the answers) and I think it might come very handy to the Note 3 community. There is a somehow similar thread for the S4 community here.
0) SUCCESS WITH KNOX / DOWNGRADING ON N900 !!!
On N900 (Exynos) there is now a solution (unfortunately for the moment only for Exynos models) - a special firmware leaked originally here:
http://sxtpdevelopers.com/samsung-note-3-knox-fix-qualcomm/
(it looks like a firmware reset/update for the EMMC, which results in the erase of the RPMB where Knox flag and downgrade restrictions are stored).
In this thread details on some of the people testing it can be found in those posts:
http://forum.xda-developers.com/showthread.php?p=52329946#post52329946
http://forum.xda-developers.com/showthread.php?p=52408318#post52408318
If the original site is taken down by Samsung you need to search after a file called BL_HA3GZS_CLEAR_WARRANTY_BIT.tar - the one I saw was 2334801 bytes in length (might be shown as a 2.23MB download in some chinese sites). There might be a problem finding it since Samsung might go after anybody hosting and distributing it.
1) Just rooting should not trip knox
The problem with rooting that makes knox 0x1 - originally Root De La Vega was developed for the AT&T very locked structure, and as such it was doing the rooting in a pretty convoluted way. However on other Note 3 versions the knox warranty flag is very clearly linked to just kernel and recovery, and not to system itself. In other words it SHOULD be possible (even after MJ3) to root and keep knox 0x0 on devices that are not "bootloader locked" by not touching kernel and recovery and only touching system - that is probably NOT going to work on AT&T (N900A) but it seems to work on N900W8 and IMHO it could also work on N9005 (and possibly N9000, but I know much less about that). If you want more proof look into the posts about N900W8 + different version (of more or less) stock-based ROMs (like xnote, but stock kernel and recovery).
So the bottom line on this is to verify on a knox 0x0 device with firmware MJ3 (or newer) that just writing a pre-rooted system would be allowed in download mode and would keep knox 0x0. And we would need a more clear confirmation for both N900W8 and N9005 (or any other models) - of course with some description of what was written and how
EDIT: some W8 users have provided extra details and so far it looks it might be more the bootloader itself and not so much in how/what is written, but more information is needed.
EDIT2: there is a thread with that kind of talk here:
http://forum.xda-developers.com/showthread.php?t=2627996
2) We should really test the "portability" of various bootloaders since this could solve a lot of things
First - here are two external (non-xda) pages with some very good development information regarding "bootloader hacking":
http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html
On bootloader-confused devices (for instance Hong-Kong versions that got the KitKat bootloader from Polish/XEO KK and have to wait for Hong-Kong KitKat, or any device that seems to be bricked in the bootloader) it might be also interesting (for somebody VERY daring - remember that it could brick your phone even worse) to try to write the bootloader files (all 5 of them?) from the N900W8 and see if those are accepted (since once that would be the case downgrading would also become a possibility).
EDIT: the N900W8 is also reported (see here) to let you have a custom recovery and not trip knox, which is kind of weird but maybe this is the knox breakthrough that we were expecting
3) More info on STRAP flags (those listed in download mode)
STRAP flags - there are a number of places where the values listed in download mode are discussed, for instance:
http://forum.xda-developers.com/showthread.php?t=2567165
It seems that the values for S T R A and P flags could be versions of the 5 main bootloader-related files used in Qualcomm-based Note 3 devices, most likely:
S - SBL1
T - TZ
R - RPM
A - ABOOT
P - SDI (?)
My EU N9005 (I believe with MI7 or so bootloader) was something like S1, T1, R1, A1, P1 and also SECUREBOOT: ENABLE (CSB) (as it can be seen in the thread above) but is now P2 (which is very strange since I had all automatic and security updates disabled, but might be related to the fact that at some point I activated the reactivation flag linked to the Samsung account - disabling it does not return P back to 1 so this might not be it).
Also if you look around the values seem to be somehow consistent - with post-MJ3 bootloader most flags become 2 and with KitKat bootloader at least the A flag becomes 3.
It remains to be seen if this is the case and if it is any way relevant to hacking the bootloader system or knox (or is just for debug purposes - like when we see people with A3 complaining that they can't return to stock MJ7 or MK2).
4) More info on "microSD debricking and if this could let us re-write different bootloader files (and maybe we should encourage people to have their "debricking image" made in advance "just in case")
When the bootloader files become "bad" and you can not go in download mode (but probably sbl1 is still valid) it is still possible to recover things by forcing the boot process from microSD. That seems to require no extra hardware on Qualcomm models and one small contact for Exynos devices (where that is even documented in Samsung original documents like 13-58_SM-N900_Boot_Recovery_Guide_rev1.0.pdf).
There is a thread on this at:
http://forum.xda-developers.com/showthread.php?t=2625332
5) More info on how Samsung CAN reset knox
There are already two threads with something more than 5-6 first-hand reports from people that went with a Note 3 knox 0x1 into service and left with the same device (and motherboard and IMEI and in some cases all their programs and even their normal/old firmware) but with knox 0x0!
One thread in T-Mobile Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2637718
And a much larger one in International Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2504258
There is also already a "hardware+software solution" (expensive, aimed at specialized phone shops that also do phone unlocking and similar stuff) which claims to be able to reset the knox flag on Exynos devices:
http://forum.gsmhosting.com/vbb/f67...olution-solution-repair-rebuild-emmc-1769456/
http://forum.gsmhosting.com/vbb/f67...bit-0-solution-inside-first-ih-world-1776265/
http://forum.gsmhosting.com/vbb/f672/regarding-knox-s4-1775213/
6) Pre-production bootloaders before knox?
Here is an interesting thread apparently about a N9005 with no knox:
http://forum.xda-developers.com/showthread.php?t=2657631

I'm not too sure if this is helpful, but with the introduction of Kitkat, the SM-N900W8 has been able to flash a custom rom/kernel and recovery without tripping Knox. I am really not sure how this is possible, but my phone is living proof of it. To my understanding we are still using the old bootloader.

(reserved for the future, I just had a very large edit on the top post and not very much extra data can fit there)

Just a note @xclub_101...you cannot write older/different bootloaders using the debrick method. gTan64 and I originally pioneered that method on the Sprint S3, and it was then ported to the other qualcomm S3's, and eventually to other Samsung devices.
It does not work. The phone will only boot with a debrick sdcard when the bootloader written to the sdcard has the same version as the corrupt one on the device emmc.
And even if an older bootloader sdcard COULD boot the device, it wouldn't matter because you would still need to Odin flash a non-corrupt bootloader to the device after using the sdcard, and it would still reject a non-Knox bootloader because of that.
So unfortunately that section is incorrect.

I can downgrade P1 to P0. It is device and carrier specific. I'm not sure what the P flag is for. RPM, SBL1, and TZ were only items modified when downgraded. All signed releases. Looking for any more information regarding these flags.

CNexus said:
Just a note @xclub_101...you cannot write older/different bootloaders using the debrick method. gTan64 and I originally pioneered that method on the Sprint S3, and it was then ported to the other qualcomm S3's, and eventually to other Samsung devices.
It does not work. The phone will only boot with a debrick sdcard when the bootloader written to the sdcard has the same version as the corrupt one on the device emmc.
And even if an older bootloader sdcard COULD boot the device, it wouldn't matter because you would still need to Odin flash a non-corrupt bootloader to the device after using the sdcard, and it would still reject a non-Knox bootloader because of that.
So unfortunately that section is incorrect.
Click to expand...
Click to collapse
That is somehow true, but IMHO if all relevant partitions are wiped on the internal flash (from SBL1 to ABOOT) then all those will be read from microSD and have the code and signatures from there, and the "Odin mode" itself will be the version from microSD.
And here we have a number of interesting paths:
- the signature/hash on SBL1 itself is similar among Note 3 versions - that would result on all steps up to and including ABOOT being valid, so the "special Odin mode" will be entered; if the signature/hash on SBL1 is NOT similar between Note 3 families (or even before and after a major bootloader version) not even the "special Odin mode" will be started;
- if "special Odin mode" is started we can see another fork - if the "downgrade limitations" are part of the microSD code itself then you will be able to write any single firmware you were able to write when the internal SBL1/ABOOT was at the same version as the microSD SBL1/ABOOT - in other words you will be able to downgrade as far back as the microSD SBL1/ABOOT will let you!
- however there are some reports that the "downgrade restrictions" are actually stored in the internal flash in the "invisible/protected" regions there - and can be reset with special JTAG-like hardware:
http://forum.gsmhosting.com/vbb/f672/regarding-knox-s4-1775213/
Even in that last case there would still be a small chance that the "downgrade restrictions" might be skipped when booting from microSD since the internal flash could be considered at that point "less reliable" (or hopefully somebody at Samsung forgot to read that extra info on this special path - we can all hope )
So yes, I would still like to see more detailed tests on it with detailed reports on what is failing at what point! And especially on the microSD with the N900W8 "happy bootloader" or even with some much earlier "early development bootloader" (I have seen something like that mentioned somewhere)!

ryanbg said:
I can downgrade P1 to P0. It is device and carrier specific. I'm not sure what the P flag is for. RPM, SBL1, and TZ were only items modified when downgraded. All signed releases. Looking for any more information regarding these flags.
Click to expand...
Click to collapse
That was on the Verizon N900V? Does that allow you to do direct downgrades or you still need some tricks? Was it still booting with the downgraded versions?

xclub_101 said:
That was on the Verizon N900V? Does that allow you to do direct downgrades or you still need some tricks? Was it still booting with the downgraded versions?
Click to expand...
Click to collapse
Downgrading is limited to the flag fuse counter values. On MJE, I can downgrade to MI9 boot image and recovery. I was able to downgrade to some pre-release engineering SBL1, RPM, and TZ because they're signed and fuse counter is only 1 for those 3. It's very benign and basic to downgrade. Just use heimdall and try downgrading an individual image. If I figure out what P is, I'll be able to test if I can flash anything related to that flag. For some reason, I can downgrade to MI9 boot and recovery, but not the system.img. I'm just starting to learn a lot about the flags/fuse counters after dissecting aboot further. If you've got any more specific questions, feel free to PM me

For the past 2 weeks I've been following the topics on Knox reset on XDA. There is so much discussion but Samsung is not at all helping.
So I was thinking we can do something like Sony Phones
On Sony Phones the trim area i.e. TA.img is backed up to restore later to claim warranty, but this should be done only before the phone is ever unlocked.
So are there any files like TA.img on Note 3 we can backup while the Knox is still 0×0 , So that if and when there is a method to reset Knox we can be ready.
If we can do this, we can go ahead and root or mod our Note 3s
So is this possible ?

iamsuperuser said:
For the past 2 weeks I've been following the topics on Knox reset on XDA. There is so much discussion but Samsung is not at all helping.
So I was thinking we can do something like Sony Phones
On Sony Phones the trim area i.e. TA.img is backed up to restore later to claim warranty, but this should be done only before the phone is ever unlocked.
So are there any files like TA.img on Note 3 we can backup while the Knox is still 0×0 , So that if and when there is a method to reset Knox we can be ready.
If we can do this, we can go ahead and root or mod our Note 3s
So is this possible ?
Click to expand...
Click to collapse
I don't think that will be possible because knox flag is an e-fuse and not a software counter.
I may be wrong, though.

FeralFire said:
I don't think that will be possible because knox flag is an e-fuse and not a software counter.
I may be wrong, though.
Click to expand...
Click to collapse
I somehow might agree to you but there's one thing about Knox which is not understandable by any means, Knox was officially introduced in Note 3 (Android 4.3) however other samsung devices had never had any hint of Knox hardware or software wise so while the official android 4.3 started rolling for other devices ie galaxy s4, note 2 etc they also got Knox and once they're tripped they cannot be reseted however I belive this should not be the case as those devices never had such thing as Knox specifically in terms of hardware and this trick has been surely done by samsung software wise and the only way to reset Knox as f now is known by samsung as few people have reported they got their Knox reset from samsung service centers, so this is kind of strange and I still believe Knox can have something to be done with software n not hardware, though I aint sure about it.........

AndroidNoob22 said:
I somehow might agree to you but there's one thing about Knox which is not understandable by any means, Knox was officially introduced in Note 3 (Android 4.3) however other samsung devices had never had any hint of Knox hardware or software wise so while the official android 4.3 started rolling for other devices ie galaxy s4, note 2 etc they also got Knox and once they're tripped they cannot be reseted however I belive this should not be the case as those devices never had such thing as Knox specifically in terms of hardware and this trick has been surely done by samsung software wise and the only way to reset Knox as f now is known by samsung as few people have reported they got their Knox reset from samsung service centers, so this is kind of strange and I still believe Knox can have something to be done with software n not hardware, though I aint sure about it.........
Click to expand...
Click to collapse
It's implemented differently on different devices. From what I've read here and on other forums, this is why:
On Note 3 Snapdragon models, the warranty bits for the kernel and recovery are actual e-fuses stored in the QFUSE block of the Snapdragon MCU (SoC), so they're "hardware" and thus permanent. EDIT: Apparently it's not permanent, as many Snapdragon owners had the Knox flag reset during service.
On Note 3 Exynos models, they're stored in the RMPB partition on the eMMC and resettable via JTAG, as they're more or less "software," which is how it's likely implemented on the older pre-Knox devices. This is also why some European Note 3 owners got their broken Note 3s back from Samsung with the Knox flag reset back to 0x0. This isn't possible on the Snapdragon models.

siraltus said:
It's implemented differently on different devices. From what I've read here and on other forums, this is why:
On Note 3 Snapdragon models, the warranty bits for the kernel and recovery are actual e-fuses stored in the QFUSE block of the Snapdragon MCU (SoC), so they're "hardware" and thus permanent.
On Note 3 Exynos models, they're stored in the RMPB partition on the eMMC and resettable via JTAG, as they're more or less "software," which is how it's likely implemented on the older pre-Knox devices. This is also why some European Note 3 owners got their broken Note 3s back from Samsung with the Knox flag reset back to 0x0. This isn't possible on the Snapdragon models.
Click to expand...
Click to collapse
The part on Exynos models is probably right since now there is a device that claims to do that - see my link in the first post.
The part with Qualcomm models is not 100% so - there are TONS of reports from people with Qualcomm models (not only N9005 in EU but also ALL T-Mobile models) that had their knox fixed on the same motherboard (and in most cases with ALL their customized software left in place). See also my links in the first post.

xclub_101 said:
The part on Exynos models is probably right since now there is a device that claims to do that - see my link in the first post.
The part with Qualcomm models is not 100% so - there are TONS of reports from people with Qualcomm models (not only N9005 in EU but also ALL T-Mobile models) that had their knox fixed on the same motherboard (and in most cases with ALL their customized software left in place). See also my links in the first post.
Click to expand...
Click to collapse
Oh, really? Awesome then, I had no idea. There is hope for us Snapdragon owners after all.

My motherboard was replaced, that's the only way KNOX can be reset according to the UK service centre I used.

P flag appears to be tied to SBL1. Was able to downgrade SBL1 by itself via Heimdall. Not sure how and why. More research needs to be done.

ryanbg said:
P flag appears to be tied to SBL1. Was able to downgrade SBL1 by itself via Heimdall. Not sure how and why. More research needs to be done.
Click to expand...
Click to collapse
I don't believe that is true. I have compared my flags with other stock btu with the same bootloader and firmware all my flags other than that my P flag is still 0
Also OP needs to recheck the sources regarding knox reset these are for warranty bit on the s4 (android 4.2.2 and below) the supposed claim of knox reset only resets the flash counter. Similar to what triangle away has done in the past
Sent from my SM-N9005 using xda app-developers app

st3chn0 said:
Also OP needs to recheck the sources regarding knox reset these are for warranty bit on the s4 (android 4.2.2 and below) the supposed claim of knox reset only resets the flash counter. Similar to what triangle away has done in the past
Click to expand...
Click to collapse
I don't understand what you are saying, you claim that the two threads below are for S4?
One thread in T-Mobile Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2637718
And a much larger one in International Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2504258

xclub_101 said:
I don't understand what you are saying, you claim that the two threads below are for S4?
One thread in T-Mobile Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2637718
And a much larger one in International Note 3 forum:
http://forum.xda-developers.com/showthread.php?t=2504258
Click to expand...
Click to collapse
Sorry I meant the links pointing towards gsmhosting. Those are perfectly fine
Sent from my SM-N9005 using xda app-developers app

st3chn0 said:
Sorry I meant the links pointing towards gsmhosting. Those are perfectly fine
...
Click to expand...
Click to collapse
Those are 3 links since I also wanted to keep some of the "history" on how that was discovered/announced, but the 3rd link is from the guy that actually sells the box and from what I see is saying:
"What this mean ? After replacing or WIPING eMMC and burning old bootloader on device with (KNOX Warranty: 0x01 ) You will get device with unknoxed boot and KNOX Warranty bit 0x0"
And then there is a long list of Exynos devices that are supported, including
Samsung SM-N900 Galaxy Note 3
Samsung SM-N9000Q Galaxy Note 3
and then a separate (and partial) list of the Snapdragon models that are NOT supported.
I have not tested the box personally and that is why I wrote from the very beginning in my original post "claims to be able to reset the knox flag on Exynos devices".
And to finish with that box and the claims they still make on Snapdragon - if they get (in a very controlled and non-destructive) way to remove the downgrading restrictions from the bootloader I think it might still be an interesting achievement - since that way you could revert any device with knox 0x0 to MI7, root and then go to whatever 4.3 or 4.4 you want. But of course that even in that scenario you need that box And on the longer term IMHO that same box might be able to reset knox on Snapdragon - yes, part of knox is in the qfuses but the final flag seems to be computed from that and some part in RPMB (which explains how Samsung resets that flags) - the really difficult part will be to find the way how the above is computed!

WHy does downgrading not work?

I see it mentioned a few times but what on the phone prevents say 4.4.2 from being installed after the upgrade to 4.4.3?

Because the partion table and bootloader are different and can't be downgraded at all.

Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?

I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?

knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.

knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
No, the Dev edition is no different. All the same "rules" apply.
The Dev edition is the same as any other.... It just keeps is warranty if you unlock it.

aviwdoowks said:
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
Click to expand...
Click to collapse
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
KJ said:
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
Click to expand...
Click to collapse
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
AGISCI said:
Because the partion table and bootloader are different and can't be downgraded at all.
Click to expand...
Click to collapse
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...

scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
It is security. Specifically the SECURED BOOTLOADER. Don't confuse secured with locked. Yes, you can unlock your bootloader, but it is still secured.
Read up on "TrustZone" and see why it is important, and why the OEMs would not want you to be able to downgrade. You can "buy" or "not buy" whatever you want....
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
The early (4.2.2 & 4.4) bootloader (motoboot.img) was vulnerable to an exploit that allowed us to disable write protection. The updated bootloader (4.4.2+) is patched. You *CAN NOT* downgrade back to the vulnerable version.
^Does that not have *everything* to do with security??

scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.

AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
Can't just fake the version number?

No, it's not possible.

samwathegreat said:
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
Click to expand...
Click to collapse
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
samwathegreat said:
You can "buy" or "not buy" whatever you want....
Click to expand...
Click to collapse
I know, and that is why I want to understand what it is I would be buying.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...

scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.

AGISCI said:
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
Click to expand...
Click to collapse
Well said :good:

Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
scryan said:
Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
Click to expand...
Click to collapse
Our recovery devs never restore such partitions or boot loader elements.

scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
Smh I normally don't chime into these threads but I had to, you can't downgrade the bootloader because of security/compatibility plan and simple. It's the same concept as why you can't downgrade most PC's bios, if there is a flaw found in the system as a whole, then they don't want you to downgrade to that version. A lot of the times when people brick their device trying to downgrade is because it will flash, but because an efuse was blown when it was upgraded the downgraded version will not boot. Yes the recovery can technically rewrite those partitions but again because the efuse was blown it will not boot. Also yes being able to downgrade on any system Windows, Linux, Unix, IOS, Xbox, PS, etc are causes to security issues. If you can downgrade a system to a vulnerable version, it is then by definition less secure, no matter how you try to spin it. Take the futex vulnerability which affected most linux kernels from the past 5 years, so why would any desktop linux user ever want to downgrade to a vulnerable kernel? They wouldn't but if the end user isn't knowledgeable of the vulnerability they wouldn't know that downgrading makes them vulnerable. So since phones are used by so many people who are not knowledgeable of vulnerabilities, why would you want to give them the opportunity to downgrade themselves to a vulnerable OS?

Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
aviwdoowks said:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
Our recovery devs never restore such partitions or boot loader elements.
Click to expand...
Click to collapse
By "Our recovery devs" do you mean the ones doing the moto specific stuff? Do you know if this Is typical of the custom recoveries for other devices?

@scryan
I know far less then other posters, but yes android recoveries are all very similar in that regard.

scryan said:
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
Click to expand...
Click to collapse
The thing is you keep looking at it from a PC point of view, where you basically have full control over the software and hardware. Phones have much tighter restrictions on them from carriers, fcc, etc they're not personal computers. So the reason they make it where you can't downgrade the bootloader is because that's what controls the restriction on downgrading any other partition on the device.
So with the Moto X's 4.4.4 update they probably blew an efuse, so users with a locked device can't downgrade. This is done because with locked devices they can only flash signed kernels, so by blowing the efuse they can't downgrade to the vulnerable 4.4.2 and below kernel even though it is signed correctly. This is because lets say a malicious app was able to get on a device that had the ability to downgrade say back to 4.2.2. That app could flash the older vulnerable signed kernel to the recovery partition, to disable write protection gain more control over the phone etc, without the users knowledge. Now that is a stretch and probably will never happen but that doesn't mean the threat isn't there, and hackers are very creative at deploying malicious attacks. So by updating the bootloader and blowing an efuse the older vulnerable kernels can't be flashed. Now this is all negated if you're unlocked of course, but if you don't want to ever worry about this issue don't update your bootloader. This is not recommended but I've mentioned it several times on this forum I haven't updated my X's bootloader since I bought it, it's still running the factory 4.2.2 bootloader, running 4.4.4 with no problem.
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.

iKrYpToNiTe said:
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
Click to expand...
Click to collapse
A bit selfish, and perhaps lazy of me but I am only really here talking about the developer version, I just haven't bothered to write the full "verizon developer edition " every time (most of this is research for next phone, which will be developer handset)... To me, obviously a locked phone is going to have weird restrictions and hacked together paths to getting things done, your not supposed to have admin rights...(yeah, maybe I do look at it too much as a computer. Mostly because I am annoyed the differences seem intentionally imposed). But when I pay outright for a device so that I can own it and have full administrative control... anyways, thats a different more philosophical discussion. The point is I have been talking about an unlocked device using third party software where possible.
Either way, appreciate the reply. I have a better understanding of the issue... Though coming from an S4 it still seems weird that MDK*/developer phones don't seem to have the same issues/warnings. It would seem however that the difference may be that MDK/dev owners only use kernels/roms prepared for their devices and do not update the bootloader. I suppose if more people in the Moto X community were worried about maintaining the ability to downgrade an unlocked device it would be technically possible to upgrade in a way that could be easily reversed, similar to the S4.
(*MDK was the first VZ S4 firmware, and the only one that has a released exploit to allow for a full custom recover. Later locked firmwares must rely on safestrap)

Installing Magisk without a patched boot image?

I'm working on modifying the source code for qu1ckr00t, a PoC from a few years ago in which magisk was installed without a patched boot image. It relied, in part, on an exploit from cve-2019-2215.
I've been able to achieve most of the same preconditions as provided by the exploit from that time, disabling SELinux and bypassing DAC and CAP. Now, the system images (but no boot images) can be modified without issue.
But getting a core-mode installation of magisk up and running through init (on the back side of the boot process, without any boot image patch) has proved to be much more challenging.
Searching this issue has proved difficult because any search turns up so many generic installation hits.
Has there been any prior project on this forum that utilized a method of installing magisk without any patch to any bootable partitions (boot/recovery)?

Search for bootless Magisk. This is basically going to be the case for any root relying on a kernel exploit since dm-verity is still active. There is a MediaTek kernel exploit from a couple years ago that was able to get Magisk working without modifying the boot/recovery images, running off the data partition instead. This method of SU/Magisk will work for managing root access to apps, but most magisk modules will fail.
Amazing Temp Root for MediaTek ARMv8 [2020-08-24]
Software root method for MediaTek MT67xx, MT816x, and MT817x! So it's no big secret that not too long ago, I found a way to achieve temporary root on MediaTek chipsets. No preinstalled root solution or device unlock was needed. The tool I...
forum.xda-developers.com
I'm surprised there are still devices out there that haven't patched cve-2019-2215.

Finnzz said:
Search for bootless Magisk. This is basically going to be the case for any root relying on a kernel exploit since dm-verity is still active. There is a MediaTek kernel exploit from a couple years ago that was able to get Magisk working without modifying the boot/recovery images, running off the data partition instead. This method of SU/Magisk will work for managing root access to apps, but most magisk modules will fail.
Amazing Temp Root for MediaTek ARMv8 [2020-08-24]
Software root method for MediaTek MT67xx, MT816x, and MT817x! So it's no big secret that not too long ago, I found a way to achieve temporary root on MediaTek chipsets. No preinstalled root solution or device unlock was needed. The tool I...
forum.xda-developers.com
I'm surprised there are still devices out there that haven't patched cve-2019-2215.
Click to expand...
Click to collapse
please port it to kernel 4.4.147+
i'll leave kernel sources:https://www.mediafire.com/file/bhzm...e_A5_2019_Pie_kernel%284.4.147%29.tar.gz/file
phone is ZTE Blade A5 2019 on Android 9, bootloader not unlockable without the code that unisoc since don't answer won't provide, zte don't care and ban mails instead but calls me valued costumer, lol

Skorpion96 said:
please port it to kernel 4.4.147+
i'll leave kernel sources:https://www.mediafire.com/file/bhzm...e_A5_2019_Pie_kernel%284.4.147%29.tar.gz/file
phone is ZTE Blade A5 2019 on Android 9, bootloader not unlockable without the code that unisoc since don't answer won't provide, zte don't care and ban mails instead but calls me valued costumer, lol
Click to expand...
Click to collapse
That was just an example of Magisk being used without modifying the boot/recovery image.
That root method requires a MediaTek processor. You can't port a code dependant vulnerability if the code it exploits is completely unrelated, like that used by a different processor.

Finnzz said:
That was just an example of Magisk being used without modifying the boot/recovery image.
That root method requires a MediaTek processor. You can't port a code dependant vulnerability if the code it exploits is completely unrelated, like that used by a different processor.
Click to expand...
Click to collapse
ah, well, yes, i'm going crazy to root this phone, ofc i know that mtksu is an exploit for mtk. unfortunately i can't root this phone , now is a year and 1 month i'm trying

I extracted kallsyms from my kernel:https://www.mediafire.com/file/pbm0nvptr3w8eab/kallsyms-4.4.147%2B_%28armv7l%29.txt/file
Now what needs to be done is to port the 32 bit version of quickroot to this kernel:https://forum.xda-developers.com/t/root-with-cve-2019-2215.3979341/post-80830899