[Kindle Fire HDX 7" & 8.9" Q&A, Help & Troubleshoot] draxie:
See the next post for a solution.!

BACKGROUND

OK. So, I had an HDX 8.9 with 14.3.2.6 all setup with towelroot, HDXposed, gapps, play store, etc.

I used to have SafeStrap on this also, but I kept running out of space; so, I got rid of it:- a foolish idea, no doubt.

Even without a ROM slot, I may have had a better chance at recovering using the built-in shell... Oh, well...

THE DEED [**SCARY**]

I was trying to follow this excellent guide -without thinking too much- :cowboy:)

Or, closer to the truth, I thought: I have root and I won't mess with the boot process; so, what could possibly go wrong?

So, I modded my build.prop:

>>> diff build.prop.orig build.prop
25,26c25,28
< ro.product.model=KFAPWI
< ro.product.brand=Amazon
---
> #ro.product.model=KFAPWI
> #ro.product.brand=Amazon
> ro.product.model=SM-G900F
> ro.product.brand=Samsung
32c34,35
< ro.product.manufacturer=Amazon
---
> #ro.product.manufacturer=Amazon
> ro.product.manufacturer=Samsung

AND, I also forgot to adjust permissions on the new build.prop.

shell@android:/system $ ls -l /system/build.prop*
-rw-rw-rw- root root 5561 2014-12-14 14:52 build.prop
-rw-r--r-- root root 5475 2014-09-09 03:53 build.prop.orig

I rebooted and got a nasty surprise: not only does the screen go black after the grey Kindle Fire logo (which wasn't too surprising), but su fails as well with exit code 1 (EPERM :- permission denied)

>>> adb shell
shell@android:/ $ su
1|shell@android:/ $ ls -al /system/xbin/su
-rwsr-sr-x root root 71264 2014-11-27 16:00 su

Permissions on the binary look OK (the same as in my backup image).

In fact, su will run with the '-v' (or '-h') option, but seems to EPERM when trying to exec another command.

shell@android:/ $ su -v
2.35:SUPERSU

STATUS

I do have a backup of the original build.prop.

I also made images of all the 20-something MMC partitions using dd.

The "brick" has adb access, and fastboot seems to work as well.

Unfortunately, the more obvious workarounds such as adb remount or fastboot boot KERNEL MODDED-RAMDISK do not help.

Interestingly, fastboot boot downloads the image before bailing out with "boot not allowed on locked hw" (or something very similar),

which _may_ (?perhaps?) allow for overflowing a buffer by messing with the fastboot protocol.. (just speculating)

While writing this up, I also tried to flash the backup of my system partition.

>>> fastboot -i 0x1949 flash system system.img
target reported max download size of 1073741824 bytes
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.020s]
sending sparse 'system' (1032534 KB)...
OKAY [ 32.464s]
writing 'system'...
FAILED (remote: flashing not allowed for locked hw)
finished. total time: 32.536s

Not only did this not work, it also got me fairly nervous as it claimed to have erased the system partition.

Luckily, that did not happen. After rebooting, the situation is the same: everything's still there, but su fails.

QUESTIONS

Do wrong permissions on build.prop alone result in such weird behavior? Or, is it more likely that the changes in content caused the lockdown?

Does 'factory reset' (from the recovery screen) fix anything in the system partition? Or, is that the same thing as Factory Reset in Settings, which clears userdata?

All the unbricking guides (specifically for build.prop mistakes) I've seen so far are based a working su. Are there other options/exploits that could be useful?

Any chance that re-rooting might help? And, in that case, does anybody know about an adb-friendly rooting method for 14.3.2.6?

Any ideas I could try to unbrick my HDX?