New Kindle Fires are locked

Search This thread

kinfauns

Retired Senior Moderator and Retired DC Lead - The
Jan 5, 2012
1,860
3,540
I've exchanged several PMs with pokey9000 today. He has taken a look at the software update packages for both the 2nd generation KF and the 7" HD. The MLO (xloader, 1st stage bootloader) is signed and the boot header is the type used for HS (high security) OMAP devices with the M-Shield turned on. If the setup is comparable to the Nook Tablet, this is not good news for those hoping to modify these devices in one way or another. The Nook Tablet's exploit was to utilize the external sdcard as an alternate boot device and that doesn't really help with these 2nd generation KFs.

It's all subject to verification by someone who has a device in hand, but it doesn't look good. This is not to say that it's impossible, but it will be considerably more difficult to manipulate these devices than their 1st generation cousin.

So, let's all hope for the best, but be prepared for the worst. If you plan to buy one of these devices, buy them as an Amazon tablet to be used in the Kindle Fire ecosystem. Don't buy them expecting to run Jelly Bean the day after tomorrow.
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,280
6,473
www.eff.org
Some clarification... and much left unanswered...

The Nook Tablet's exploit was to utilize the external sdcard as an alternate boot device and that doesn't really help with these 2nd generation KFs.

Not quite right. NT's exploit was far more complicated than that and has nothing to do with using the external SD card (or depending on one). It could have been done simply with root (or any other method for overwriting a partition, which was required to insert a 2nd unsigned bootloader into the boot sequence). If you're curious, you can look at the CyanoBoot 2nd bootloader for NT description or source to see what's going on.

I've taken a VERY quick look at the bootloader source for the HD7 as well, pushed here for anyone who wants it. There is in fact signature verification code in the uboot source (~line 140).

Also, looks like there are three configs-- bowser, jem, and tate. I have to look at it closer but it looks like tate is a subtype of bowser, and the HD7 I assume is tate. Hashcode also found a "radley" in the kernel code, but I haven't looked at that.

Anyway.. it is possible that bauwks' flaw or some other flaw exists in this signature verification code, but the code isn't identical to NT so who knows.

Incidentally, the new revision of the Kindle Fire (otter2) also has the same code, and there's a thread about the signature issue here as well.

It's all subject to verification by someone who has a device in hand, but it doesn't look good. This is not to say that it's impossible, but it will be considerably more difficult to manipulate these devices than their 1st generation cousin.

So, let's all hope for the best, but be prepared for the worst. If you plan to buy one of these devices, buy them as an Amazon tablet to be used in the Kindle Fire ecosystem. Don't buy them expecting to run Jelly Bean the day after tomorrow.

Yeah.. it all depends on whether there's a flaw as there was with the Nook Tablet... someone get bauwks on the line :)

Meanwhile, I'm enjoying my free (as in speech) Nexus 7... :p
 

pokey9000

Senior Member
Apr 17, 2007
767
396
Austin
Not quite right. NT's exploit was far more complicated than that and has nothing to do with using the external SD card (or depending on one). It could have been done simply with root (or any other method for overwriting a partition, which was required to insert a 2nd unsigned bootloader into the boot sequence).

Technically true, but altering the boot chain with a removable microSD makes it a reversible process. Overwriting the boot image on emmc without any other boot options is serious brown trousers time. Now if they left in fastboot, then its not so scary if a similar hack to the NT can be done. Still, with no possibility of USB boot there's no recourse if any exploits get patched.
Meanwhile, I'm enjoying my free (as in speech) Nexus 7... :p

Yes.

Sent from my Nexus 7 using xda premium
 
  • Like
Reactions: kinfauns

kinfauns

Retired Senior Moderator and Retired DC Lead - The
Jan 5, 2012
1,860
3,540
Not quite right. NT's exploit was far more complicated than that and has nothing to do with using the external SD card (or depending on one). It could have been done simply with root (or any other method for overwriting a partition, which was required to insert a 2nd unsigned bootloader into the boot sequence). If you're curious, you can look at the CyanoBoot 2nd bootloader for NT description or source to see what's going on.

...

Thanks for the clarification and your input as well. I just wanted to get the discussions going on the possibilities of opening up this device to development, but also temper some expectations. There are many people waiting and some undoubtedly have ordered with the assumption that these 2nd generation devices will be getting the full range of development enjoyed by the original. I was mostly paraphrasing and summarizing, so I'll leave the details to those with the know-how.

I'm sure many people will be scouring the code and tinkering with their new devices in the coming days to figure something out.
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,280
6,473
www.eff.org
Boring stuff...

Technically true, but altering the boot chain with a removable microSD makes it a reversible process. Overwriting the boot image on emmc without any other boot options is serious brown trousers time

It's not THAT risky, I don't think. Even w/o SD card on NT, the safe(st) way to do it would be to replace the recovery partition with a 2ndboot/cyanoboot-enhanced recovery.img from a normal rooted boot. If recovery fails, you're still okay-- you can always just boot normally, gain root, and replace recovery again. If you're verified good, then use recovery to replace boot.img.

On NT, the normal secure boot sequence is unaffected when you replace recovery. That's because on the NT, you are never removing or touching the original uboot (ub1), so there's not much danger of a brick as long as you always have two means for booting (normal + recovery).

This is all academic as far as KFire HD goes, as I'm guessing from existence of the "crypto" partition that bauwks' bugfix won't work. I need to give a look at the signature verification stuff, as I haven't looked at it yet, but I'm not particularly optimistic.

Now if they left in fastboot, then its not so scary if a similar hack to the NT can be done. Still, with no possibility of USB boot there's no recourse if any exploits get patched.

True, although w/NT, BN can only patch it by modifying the hardware, which would create massive support headaches for two versions of the boot. This is because w/unchanged hardware, the current, signed xloader->ub1->ub2 chain can always be used to load whatever. Again, I have more clarification on this-- if you're not already familiar with the details, find me on IRC.

speaking of fastboot, apparently if CONFIG_MACH_BOWSER_SUBTYPE_TATE is set, fastboot_idme is defined and fastboot and other debugging stuff seems to be turned on. I'm pretty sure "idme" is a uboot command. It's commented-out of drivers/fastboot.c as a shortcut to be enabled for TATE only.

FWIW, here are some various versions of the bowser board:

Bowser-Jem-PreEVT2-
Bowser-Jem-PreEVT2-
Bowser-Tate-PreEVT2.1-
Bowser-Tate-PostEVT2.1-
Bowser-Tate-PostEVT3HS2-
Bowser-Tate-DVT-
Bowser-Tate-PVT-
Bowser-Radley-


tate = product id 7
jem = product id 8
radley = product id 9
HS is High Security, I'm pretty sure.

Someone apparently is a fan of To Kill a Mockingbird (Boo Radley, Atticuls "Jem" Finch, Heck Tate, etc.). I don't know what the Bowser connection is... this guy? Or maybe just one of these.

Gotta go.
 

wrexus

Member
Jun 20, 2011
35
2
This was probably done in response to all the bricked Kindle Fires that were returned with the original Fire. That and the fact that if they didn't, it probably would have meant a price increase due to increased warranty expense. However, it seems i would make sense to simply allow an owner to pay a small fee to unlock the boot loader and register a modified Fire as "no warranty" for software issues.
 

psomero

Member
Dec 3, 2008
19
7
San Jose
I've exchanged several PMs with pokey9000 today. He has taken a look at the software update packages for both the 2nd generation KF and the 7" HD. The MLO (xloader, 1st stage bootloader) is signed and the boot header is the type used for HS (high security) OMAP devices with the M-Shield turned on. If the setup is comparable to the Nook Tablet, this is not good news for those hoping to modify these devices in one way or another. The Nook Tablet's exploit was to utilize the external sdcard as an alternate boot device and that doesn't really help with these 2nd generation KFs.

It's all subject to verification by someone who has a device in hand, but it doesn't look good. This is not to say that it's impossible, but it will be considerably more difficult to manipulate these devices than their 1st generation cousin.

So, let's all hope for the best, but be prepared for the worst. If you plan to buy one of these devices, buy them as an Amazon tablet to be used in the Kindle Fire ecosystem. Don't buy them expecting to run Jelly Bean the day after tomorrow.

I got my 7" Fire HD in the mail yesterday and am in this 100% to see custom roms running on it.

While I have just under a year of Android tinkering under my belt and many more years of experience playing with pc's and various flavors of embedded systems, I dunno where it all begins for this new device, but I want to help the dev community in any way I can.

If anybody has specific requests about the device or needs to test out something on one, I don't mind being a guinea pig, as long as there isn't too much risk of bricking my cool new toy...
 

deeper-blue

Senior Member
Nov 28, 2010
58
609
somewhere in good ol' Germany
I will take a look at the u-boot sources of the new fires too and see how/what they have changed. Very possible that they fixed the funny flaw in the loading process for this iteration of their devices.
It would certainly be sad since a full HD android tab is tempting. At least for the 7inch category we have the nexus7 as an extremely good alternative.
 

bournezhang

Senior Member
Dec 31, 2011
60
11
Technically true, but altering the boot chain with a removable microSD makes it a reversible process. Overwriting the boot image on emmc without any other boot options is serious brown trousers time. Now if they left in fastboot, then its not so scary if a similar hack to the NT can be done. Still, with no possibility of USB boot there's no recourse if any exploits get patched.

Yes.

Sent from my Nexus 7 using xda premium

just wait for pokey9000 to answer , wait for u have idea how to USB boot it
 

robertc88

Senior Member
Jan 27, 2012
292
29
I got my 7" Fire HD in the mail yesterday and am in this 100% to see custom roms running on it.

While I have just under a year of Android tinkering under my belt and many more years of experience playing with pc's and various flavors of embedded systems, I dunno where it all begins for this new device, but I want to help the dev community in any way I can.

If anybody has specific requests about the device or needs to test out something on one, I don't mind being a guinea pig, as long as there isn't too much risk of bricking my cool new toy...

Well I for one will be quite happy if someone can get an alternate launcher to work without rooting. Didn't have to on the original KF for them to work.

---------- Post added at 12:50 PM ---------- Previous post was at 12:46 PM ----------

I have already hit the Return Item button on this. I could care less about the speakers and the screen! Gonna pick up the Nexus 7 instead.

I hope not cause the Nexus 7 for those two things ain't as good as this Fire HD.
 

DrWowe

Senior Member
Mar 20, 2006
65
113
Worst case scenario, there's always the kexec option. As a last resort, it works even on devices where the bootloader was never cracked.
 

ZilverZurfarn

Senior Member
Feb 11, 2009
970
23
Göteborg
Well I for one will be quite happy if someone can get an alternate launcher to work without rooting..
Yes, that would do it for me too (along with some ability to sideload apps). I preordered the 8.9 HD so I'll keep close watch on the development. If no solution is found before end of November, I just might cancel, and look around for what's hot (and rootable) at that point.
 

pokey9000

Senior Member
Apr 17, 2007
767
396
Austin
just wait for pokey9000 to answer , wait for u have idea how to USB boot it

USB boot needs a special boot loader (aboot in omap4boot used in Firekit) , and at least on the Nook Tablet it needs to be signed too. I doubt that TI's customers can or would opt for locking just flash boot so I'm going to assume that it won't work on the new Fires without a signed USB loader.
 

smirkis

Senior Member
Oct 8, 2010
1,820
611
San Diego, CA
glad to see everyone brainstorming over here. sorry for the bad news. i'm gonna follow these closely as i want to get a kfire hd for the gf eventually, but only when this bootloader gets unlocked. til then, back over to my n7 (which i find boring at times, because everything just works... bummer) lol
 

Loglud

Senior Member
Jul 29, 2011
235
449
It's not THAT risky, I don't think. Even w/o SD card on NT, the safe(st) way to do it would be to replace the recovery partition with a 2ndboot/cyanoboot-enhanced recovery.img from a normal rooted boot. If recovery fails, you're still okay-- you can always just boot normally, gain root, and replace recovery again. If you're verified good, then use recovery to replace boot.img.

On NT, the normal secure boot sequence is unaffected when you replace recovery. That's because on the NT, you are never removing or touching the original uboot (ub1), so there's not much danger of a brick as long as you always have two means for booting (normal + recovery).

This is all academic as far as KFire HD goes, as I'm guessing from existence of the "crypto" partition that bauwks' bugfix won't work. I need to give a look at the signature verification stuff, as I haven't looked at it yet, but I'm not particularly optimistic.



True, although w/NT, BN can only patch it by modifying the hardware, which would create massive support headaches for two versions of the boot. This is because w/unchanged hardware, the current, signed xloader->ub1->ub2 chain can always be used to load whatever. Again, I have more clarification on this-- if you're not already familiar with the details, find me on IRC.

speaking of fastboot, apparently if CONFIG_MACH_BOWSER_SUBTYPE_TATE is set, fastboot_idme is defined and fastboot and other debugging stuff seems to be turned on. I'm pretty sure "idme" is a uboot command. It's commented-out of drivers/fastboot.c as a shortcut to be enabled for TATE only.

FWIW, here are some various versions of the bowser board:

Bowser-Jem-PreEVT2-
Bowser-Jem-PreEVT2-
Bowser-Tate-PreEVT2.1-
Bowser-Tate-PostEVT2.1-
Bowser-Tate-PostEVT3HS2-
Bowser-Tate-DVT-
Bowser-Tate-PVT-
Bowser-Radley-


tate = product id 7
jem = product id 8
radley = product id 9
HS is High Security, I'm pretty sure.

Someone apparently is a fan of To Kill a Mockingbird (Boo Radley, Atticuls "Jem" Finch, Heck Tate, etc.). I don't know what the Bowser connection is... this guy? Or maybe just one of these.

Gotta go.

fattire is a beast for doing work on the Nooktablet with me, chm and all the other guys.... From what im reading, its actually kinda like booti from the Nook tablet. Very very interesting file at ./common/cmd_idme.c It seems as though theres a way to load a debugging kernel. Kinda curious if we can use that to smash a new boot into it. The following lines interest me:

./common/cmd_idme.c
Code:
#ifdef ENABLE_DIAG_KEY
        if (!val_vol_up && val_vol_down) {
                /* button up is pressed only */
                printf("Tablet: Enter dkernel mode: ....\n");
                *ptn = pdkernel;
        }

Code:
        case '2':
                printf("Select Diagnostic image\n");
                *ptn = pdkernel;
                break;

and also this line in the ./include/config/tate.h
Code:
#define CONFIG_DIAGNOSTIC_BOOTCOMMAND "mmcinit 1;mmc 1 read 0x580 0x81000000 0x600000; bootm 0x81000000"


As for the boot hole that bauwks discovered on the nook tablet, it is not on this device, though it is highly possible that if this Diagnostic mode can be activated we can use the same exploit as we used with the fatload and the booti. This CONFIG_DIAGNOSTIC_BOOTCOMMAND can maybe do the same thing with something in the SAR memory, so its worth someone doing somemore research.
 
  • Like
Reactions: sunsurfer42

adrian816

Member
Aug 2, 2012
42
6
Ifixit has a teardown of the device, and there is a big test point labeled "USB BOOT" on the main board, and two smaller ones labeled "RX" and "TX"....

http://guide-images.ifixit.net/igi/UapMeZFPXthjTrEn.huge

One way to make the device harder to alter is by making these test points the physical connections for a bootloader USB port. Perhaps the USB port accessible to the user is solely intended as a data transfer port for multimedia where the driver is initialised only after the anti-hacking measures are loaded?
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,095
25,088
Owego, NY
USB boot needs a special boot loader (aboot in omap4boot used in Firekit) , and at least on the Nook Tablet it needs to be signed too. I doubt that TI's customers can or would opt for locking just flash boot so I'm going to assume that it won't work on the new Fires without a signed USB loader.

This is standard operating practice. You can be assured that if flash boot is locked, USB boot will also be locked.

Interesting tidbit: While no Samsung Android device other than the Verizon GS3 (and rumor has it, upcoming Verizone Note 2) has a locked bootloader in terms of ability to boot a kernel, nearly ALL of them have the initial first stage of boot locked. It's just that Samsung usually drops the chain of trust early on. This is, for example, why Unbrickable Mod doesn't exist for any GS2 or GS3-family device - No one has access to a signed USB-bootable IBL/PBL/SBL setup. (Technically, one could likely USB-boot the existing IBL, but that IBL is hardcoded to go to flash for PBL/SBL.)

So far, no one I am aware of has ever compromised the low-level hardware enforcement of OMAP4 HS or Exynos4. In all cases of OMAP4, any compromise took advantage of holes in the chain of trust farther down the line - however nearly all attack vectors are known, so probably every compromise technique that is standard (kexec, second init, etc.) has a countermeasure in play with the KFHD if they're THAT confident in its unbreakability. In the case of Exynos4, in all current cases the chain of trust goes "insecure" so early that only people with clobbered bootloaders care.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 21
    I have a hijack I'm working on for recovery and custom roms, but its literally the messiest thing I've ever had to do.

    1. There are no exec binaries used in the pre-services portion of the init.*.rc script, like logwrapper. These make for very good hijack points, because they literally pause the boot.
    2. There is no charge-only mode on the Kindles. So, can't use that either.
    3. Since I'm hijacking at a point where the actual android services are already coming up, it means that bootanim and then zygote will try and take over anything I display on the screen (ie: a splash menu for choosing recovery)
    4. Also since the hijack is so late in the start up, its a fairly complicated fork/cleanup process so that 2nd-init doesn't hang on a running service or locked mount.

    So the hijack currently is setup like this:
    1. I insert the splashscreen for entering recovery via 2nd-init at a core service called "setup_fs".
    2. This service is started maybe 1/2 a second before surfaceflinger and bootanim.
    3. To use this, I currently have to rename servicemanager to servicemanager.bin which causes a stall in the services when this fails to load. Its a chain reaction, also causing bootanim, zygote and media services all to hang as well.
    4. At this point user has 8 seconds to choose 'recovery' or 'continue' by pressing either button on the screen, and if 8 seconds goes by, then the script defaults to continue.
    5. In any of the 3 cases below, the init is restarted via 2nd-init:
    5a. Recovery: I drop a new ramdisk in place and off we go.
    5b. If a custom ROM is configured on a rom-slot, then I pull that rom's rootfs and drop it in place before restarting init.
    5c. If a stock boot is active, I drop a fixed init.*.rc script which starts both setup_fs normally w/o the hijack and calls servicemanager.bin correctly so the services don't hang. And it boots up normally the 2nd time.

    All in all adds about 20 seconds to the boot up.

    It's not working right yet either, I'm still debugging the cleanup scripts etc. But, everything I see indicates that custom recovery/roms should be doable.

    Sent from my XT894 using Tapatalk 2
    6
    I've exchanged several PMs with pokey9000 today. He has taken a look at the software update packages for both the 2nd generation KF and the 7" HD. The MLO (xloader, 1st stage bootloader) is signed and the boot header is the type used for HS (high security) OMAP devices with the M-Shield turned on. If the setup is comparable to the Nook Tablet, this is not good news for those hoping to modify these devices in one way or another. The Nook Tablet's exploit was to utilize the external sdcard as an alternate boot device and that doesn't really help with these 2nd generation KFs.

    It's all subject to verification by someone who has a device in hand, but it doesn't look good. This is not to say that it's impossible, but it will be considerably more difficult to manipulate these devices than their 1st generation cousin.

    So, let's all hope for the best, but be prepared for the worst. If you plan to buy one of these devices, buy them as an Amazon tablet to be used in the Kindle Fire ecosystem. Don't buy them expecting to run Jelly Bean the day after tomorrow.
    6
    Some clarification... and much left unanswered...

    The Nook Tablet's exploit was to utilize the external sdcard as an alternate boot device and that doesn't really help with these 2nd generation KFs.

    Not quite right. NT's exploit was far more complicated than that and has nothing to do with using the external SD card (or depending on one). It could have been done simply with root (or any other method for overwriting a partition, which was required to insert a 2nd unsigned bootloader into the boot sequence). If you're curious, you can look at the CyanoBoot 2nd bootloader for NT description or source to see what's going on.

    I've taken a VERY quick look at the bootloader source for the HD7 as well, pushed here for anyone who wants it. There is in fact signature verification code in the uboot source (~line 140).

    Also, looks like there are three configs-- bowser, jem, and tate. I have to look at it closer but it looks like tate is a subtype of bowser, and the HD7 I assume is tate. Hashcode also found a "radley" in the kernel code, but I haven't looked at that.

    Anyway.. it is possible that bauwks' flaw or some other flaw exists in this signature verification code, but the code isn't identical to NT so who knows.

    Incidentally, the new revision of the Kindle Fire (otter2) also has the same code, and there's a thread about the signature issue here as well.

    It's all subject to verification by someone who has a device in hand, but it doesn't look good. This is not to say that it's impossible, but it will be considerably more difficult to manipulate these devices than their 1st generation cousin.

    So, let's all hope for the best, but be prepared for the worst. If you plan to buy one of these devices, buy them as an Amazon tablet to be used in the Kindle Fire ecosystem. Don't buy them expecting to run Jelly Bean the day after tomorrow.

    Yeah.. it all depends on whether there's a flaw as there was with the Nook Tablet... someone get bauwks on the line :)

    Meanwhile, I'm enjoying my free (as in speech) Nexus 7... :p
    5
    I was discussing with kinfauns about the possibility of modifying a backed up system.img into a fastboot flashable ROM/theme/mod and I was told, more or less, that the boot image has a signed header based on the contents of the system partition.

    How is this going to effect how ROMs are made for the 2nd gen. devices?
    Or is my interpretation of it completely wrong?

    ROMs can be made with 2nd-init in mind (or any other exploit which is found).

    They don't include kernels for the most part. But they can have custom rootfs files which are extracted just before the 2nd-init (restarting of the "init" process) happens. So as long as you can use the stock kernel, the sky is the limit.

    It's not a perfect scenario, but the ROM devs for Motorola phones have been working around this limitation for a couple of years now.

    The biggest downside with 2nd-init development is aging of the device. If the manufacturer doesn't update the kernel then over time it gets harder and harder to put newer versions of Android on it.

    The other issue is that custom recovery becomes much more important. If the recovery/bootstrap system works well and handles the .zip files the right way-- then flashing and using a locked device with custom ROMs is still a ton of fun. But, if the recovery is janky and users are constantly flashing into soft-bricks or breaking signatures which require a length re-flashing of the system software ... well that's NOT fun.
    4
    More fun observations from the source code...

    A little more info for anyone who might care... just from looking at the bootloader code, it looks like this is basically what happens...

    so the uboot command used to load the boot.img should look SOMETHING like this:

    "booti mmc1"

    this calls do_booti() in common/cmd_bootm.c, which is hardwired to load the kernel to 0x80008000 (adjusted for the security header)

    but first, before it's loaded authentify_image() is run. It's going to check the image size by first loading a fragment of the certificate which contains the length. Then it loads the rest of the image and runs certificate_signature_verify() which calls the OMAP4 HS API routines I guess that does the heavy lifting.

    If it fails, it shows this image, converted from rle, thanks to [mbm].

    nhzwM.png


    The only thing I can find of interest is that the size in the header isn't really verified in authentify_image(). The size is calculated like this:

    nb_bytes = ISW_hash_struct_ptr->length + ISW_hash_struct_ptr->start_offset;
    nb_bytes -= FIRST_FRAGMENT_SIZE_IN_BLOCKS*512; // removed block which have been already loaded


    Just spitballing, but length and start_offset aren't checked...

    from include/asm-arm/arch-omap4/omap4_signature.h

    typedef struct
    {
    u32 start_offset;
    u32 length;
    u8 hash[20];
    }CERT_Hashes;


    I don't know if anything can be done with that... Bauwks?

    Also, kinda funny... the file drivers/initlogo.rle has apparently been GPL'd by Amazon. Converted to png, again by [mbm], it looks like this. Did Amazon just GPL the kindle's logo? (FWIW, Barnes and Noble replaced the NookColor's u-boot startup logo with a dummy one.)

    Anyway, still enjoying my open and free-as-in-speech N7...