yashsingh1/xdaforums huggingface dataset:
[7" Kindle Fire HD General] Entropy512:
It's possible to have a secure recovery method without allowing holes. It's just that historically, companies have ****ed up by not thinking it through (see Verizon GS3 not integrity-checking recovery on execution, and the Nook Tablet dropping the chain of trust too early when doing a recovery operation, both of which allowed the recovery sequence to get hijacked.)

I wouldn't be surprised if Amazon learned from those failures and have a chain of trust that goes through the full recovery process - for example, a signed USB-bootable bootloader that will only flash signed images to eMMC.

Then, you can distribute a "complete factory reset" package that is signed and unmodifiable, but lets devices be unbricked easily.

As to the use of anything from HTC devices - Nothing for HTCs is likely to be usable. No HTC device I'm aware of uses OMAP4, and HTCs security architecture is, simply put... weird. (Partly due to using Qualcomm processors...) The whole "unlocked but S-ON" **** is stupid and a sign of an overly complex security architecture - and the more complex your architecture is, the more likely you are to **** it up and put in a hole.
[7" Kindle Fire HD General] thebeastglasser:
So what I get out of this is that the Kindle is never going to have a software update because of this flaw (or a positive if you go by Amazon's side) and if they ever do... it could be possible to modify it and place it into the Kindle using the Stock recovery and/or use the "flaw" in the security to put our own modified ROMs on it. Am I right by saying this? Or am I still living in a dream world.
[7" Kindle Fire HD General] Entropy512:
No. Amazon can easily deploy updates - they have the signing keys.

The way it works is, when booting:

CPU checks the signature of the first stage in the boot sequence (MLO in this case I believe)

The first stage in the boot sequence executes IF the signature check passes. This stage then uses the CPU or keys stored internally within it to verify the next stage in the boot sequence (U-boot in this case I believe). Even if it's a software check, if the verification key is signature-checked itself, you can't alter it.

The second stage in the boot sequence executes IF the signature check passes. This stage then verifies the kernel and ramdisk, and boots them.

In many devices, the next stage of boot is to start executing stuff in /system. If this isn't signature-checked, it's possible to hijack the boot sequence here (second init). Amazon could have added some signature checks here to stop hijacks.

In the case of the Verizon GS3, the recovery was not signature checked at all. As a result, it was easy to hijack it for various purposes. You could never get the device to directly boot from the operational kernel partition, but it was easy to kexec an operational kernel from the unchecked recovery partition. I'm positive Amazon didn't leave their recovery wide open like this - it's almost surely signature-checked.

In short, if Amazon did their bootloader engineering right, it's possible for Amazon to recovery any bricked device, even to distribute a recovery method to "the field", and to update their software, because they have the signing keys for the Fire. However, people WITHOUT the signing keys can't modify anything that is signature-checked.
[7" Kindle Fire HD General] fattire:
Also...

Also, FWIW:

regular boot kernel:

Linux version 3.0.8-02695-g518413c (ubuntu@ip-10-174-95-198) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Mon Sep 10 00:54:22 UTC 2012

eng boot kernel:

Linux version 3.0.8-02695-g518413c (ubuntu@ip-10-222-193-222) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Mon Sep 10 04:47:40 UTC 2012

The ramdisks appear to be identical.
[7" Kindle Fire HD General] Entropy512:
Yup. Recovery wasn't checked at all. In theory you could then use it for regular boot, but as you said, you'd lose recovery. Until the security-dropped bootloader got leaked, the solution was to build kexec support into recovery, and then you'd "flash an update" that had an update-binary configured to kexec an operational kernel. They also had some second-init style hacks that checked the kernel commandline, and if it wasn't kexeced, it would do an autoreboot into recovery and it would "flash" the kexec "update".

JTAG is likely the answer for screwing stuff with this.

The chances of those eng images being security-dropped (e.g. allow unsigned images to boot) is less than 1% in my opinion. Including signed security-dropped binaries in an update would be stupid on a grand scale, unless your goal was to unlock the device forever.

That script that is checking the manfid might possibly be checking for Samsung chips and only enabling the discard mount option if it's NOT a Samsung... Fear of Superbrick, since Samsung's storage guys still seem to be shipping old defective chips to third-party vendors. (No Samsung device released in 2012 has a defective eMMC, but the Acer A700 does, for example.)
[7" Kindle Fire HD General] fattire:
More irrelevant nonsense.

Yeah, the prod/eng kernels seem almost identical. There are four tate defconfigs in the kernel, and ignoring the two debug versions, the difference is this:

diff android_tate_defconfig android_tate_trapz_defconfig

61a62

> CONFIG_SUSPEND_TIME=y

280a282

> CONFIG_HDMI_CERT_DEBUG=y

344a347,348

> CONFIG_TRAPZ=y

> CONFIG_TRAPZ_DETAIL=y

384a389,391

> # Enabling Oprofile

> CONFIG_PROFILING=y

> CONFIG_OPROFILE=y

TRAPZ is TRAPZ (TRAcing and Profiling for Zpeed) according to /include/linux/trapz.h. Uses specific compiler flags and such. Some type of logging thing I guess. Is that what makes the eng build special? I have no idea.

And yeah, since the eng kernel has a header, it probably (99%, agreed) means that the eng uboot requires it :P
[7" Kindle Fire HD General] Loglud:
\

Defiantly agree with that. From what I know about built in security on chip is that it most likely uses a one time built in Floating Gate Transistor to write a configuration bit that makes it so that it checks the security of the boot. What does this mean? It means that theres no way to really "override the boot". It seems that with these physical security measures that it would be nearly impossible to boot a non-signed x-loader and bootloader if they did it correctly. Most likely once the bit is set, all instruction sets that get loaded into memory have to be verified, however this is true only for when the instruction set gets loaded, anything that is loaded in the instruction set is loaded and verified only if its asked for. IDK though its just a theory. Dont have a device and dont plan on buying one, but i would assume that after the OMAPS i have messed with this is how they do it.
[7" Kindle Fire HD General] noxwell:
On what chip the key, that checks x-loader, is hardcoded? My thoughts is to rewrite or read this key directly from chip. If it's not possible, maybe we can extract chip from MB and put it on devboard for bruteforcing the key. And as i know, FGMOS is rewritable, it is not efuse
[7" Kindle Fire HD General] Hashcode:
The easy answer for getting around undefeatable bootloader security is to setup what I've done for the Motorola phones I support (with locked bootloaders):

In their case, I took CWM and modified it to flash to a special 2nd system/data partition.

During the boot, a splash screen gives the user the option of booting into this special recovery due to the main recovery being signed and unusable.

If the user doesn't select recovery, then it checks a toggle file to see if the 2nd system boot is active. And if so checks for 2 types of 2nd system boots:

1. If there are files in the 2nd system to support a kexec kernel boot, then the start sequence immediately jumps to that and starts the kexec process which also includes a new ramdisk.

2. Otherwise its a 2nd-init boot, which reloads a new ramdisk, clears out any open files/mounts/sockets and then restarts the init process over again using the stock kernel.

Both of these use the 2nd system area and an alternate data mount to load the new ROM.

I call it Safestrap, because its a modified bootstrap/recovery which doesn't clobber your main OS during flashes which potentially could cause a brick.

It's currently in use for: Droid 3, Bionic, RAZR/MAXX and Droid 4.
[7" Kindle Fire HD General] Hashcode:
Here's the splash screen which shows during the device boot.
[7" Kindle Fire HD General] fattire:
Can kexec via module be used to start a bootloader, or just another kernel?

If a new, unsigned bootloader could be used, then cyanoboot's menu (advantage: already written for uboot) could be used from there to do whatever.... might be a little easier/cleaner albeit a slower boot.

Just a thought.
[7" Kindle Fire HD General] Hashcode:
Just another kernel. Basically the splash-screen/hijack point acts like a mid-stage bootloader allowing for recovery or 2nd-system boot.
[7" Kindle Fire HD General] fattire:
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].

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...
[7" Kindle Fire HD General] angelusnovus:
is this new kindle a worth product?
[7" Kindle Fire HD General] wizardknight:
No, you should invest in an abacus.
[7" Kindle Fire HD General] craby1925:
If you lack any adventurousness at all in your soul, spend your money on the abacus, it will do you much better.
[7" Kindle Fire HD General] Ha1cy0n:
This is by FAR the most interesting and informing thread I've ever read on this website. Thank you to all the developers that have been following this thread. Never seen so many beast devs in one thread before!
[7" Kindle Fire HD General] a24kgoldphoto:
Afraid your right...

I purchased a FireHD on 09/22 got delivery 09/25 and seem to have missed the 1stgen boat tried to access device serial# with ADB with 2 different computers that read the ser# on Nexus 7 first time every time without any trouble looks like I'll have to stick with the nexus7 till someone figures out how to crack the fireHD.
[7" Kindle Fire HD General] Ectoplasmic:
Has there been any progress in getting around the locked bootloader? I don't see any custom ROMs for the KF HD, so I assume that it's still locked down.
[7" Kindle Fire HD General] wkpark:
the MLO signing tool could be found in the tarball of the GB version of LGE SU760.

http://www.lg.com/global/support/opensource/opensource-detail.jsp?detailCustomerModelCode=LGSU760

I just remove all RSA keys found at this tarball.

I guess these RSA keys and the signing tools are accidentally leaked by mistake.

this is some usage of the ift tool that Ive found

ift -help

# show help msg of the "parse" command
ift M -parse -help

# print all keys found at the MLO file
ift M -parse -input MLO_file_name -type keys
[7" Kindle Fire HD General] craby1925:
Are you skilled in using this tool?
[7" Kindle Fire HD General] wkpark:
little bit. but there are some script exists included in the tarball and I can make a MLO / 2ND signed bootloader for the omapflash/omap4boot.

I can also sign u-boot images with modified script for LG Prada3.0(SU540) / SU760 / SU870 etc.
[7" Kindle Fire HD General] Jiggity Janx:
Sign new KF HD bootloaders?!?

Bump cause I don't know if I'm reading the above correctly and no one has noticed or if I'm off base...

I THINK HE'S SAYING HE CAN BUILD AND SIGN BOOTLOADER FOR THE KF HD....? THAT MEANS A BOOTLOADER CAN BE CREATED TO RUN WHATEVER KERNEL IT'S POINTED AT?

Someone help me out here...
[7" Kindle Fire HD General] soupmagnet:
If I understand correctly, unless you can get the private signing keys from Amazon, it's pretty much a moot point.

You can create a signed bootloader all you want, but if the signed headers of the bootloader, recovery.img, and all boot.img's don't match what is hard-coded into the chip itself, it won't work and you'll end up with another permanently bricked device.
[7" Kindle Fire HD General] wkpark:
NO. that's not the point. you can't make a bootable bootloader without RSA private keys of Amazon.

$ MLO/ift/ift M -parse -input /tmp/MLO -type keys
*******************************************************************************
* (C) 2010 TEXAS INSTRUMENTS FRANCE. WTBU. All rights reserved *
* M-Shield Image Formatting Tools ==> IFT: Release 0.991 *
*******************************************************************************
* This product includes software developed by the OpenSSL Project for use *
* in the OpenSSL Toolkit. (http://www.openssl.org/). *
* This product includes software written by Tim Hudson (tjh@cryptsoft.com) *
* This product includes cryptographic software written by Eric Young *
* (eay@cryptsoft.com). Please read LICENSE.txt. *
*******************************************************************************
Image MultiTask format
-----------------------------------------------------------------
Public Key Certificate Certificate description
-----------------------------------------------------------------
info magic (8) -> CertPK_
info type (4) -> 0xffffffff
info version (4) -> 0xffffffff
min version pk (4) -> 0x00000000
min version ppa (4) -> 0x00000000
min version rd1 (4) -> 0x00000000
min version rd2 (4) -> 0x00000000
min version isw (4) -> 0x00000000
min version pas (4) -> 0x00000000
min version pau (4) -> 0x00000000
min version ki (4) -> 0x00000000
number of keys (4) -> 0x00000006
boot swd (4) -> 0x00000000
pk right limit (4) -> 0xffffffff

[b]root key[/b] (276)/ id->0x00000001 rights->0x00000001 type->0x00000000
-> Hash Algo: SHA1 -> Signature Algo: PKCS1.5
-> sig rights: |pk

key 0 (276)/ id->0x00000002 rights->0x00000002 type->0x00000000
-> Hash Algo: SHA1 -> Signature Algo: PKCS1.5
-> sig rights: |isw

key 1 (276)/ id->0x00000003 rights->0x00000006 type->0x00000000
-> Hash Algo: SHA1 -> Signature Algo: PKCS1.5
-> sig rights: |isw|ppa

key 2 (276)/ id->0x0000000c rights->0x00000008 type->0x00030001
-> Hash Algo: SHA256 -> Signature Algo: PKCS2.1
-> sig rights: |pau

key 3 (276)/ id->0x0000000d rights->0x00000010 type->0x00030000
-> Hash Algo: SHA256 -> Signature Algo: PKCS1.5
-> sig rights: |pas

key 4 (276)/ id->0x0000000e rights->0x00000020 type->0x00000000
-> Hash Algo: SHA1 -> Signature Algo: PKCS1.5
-> sig rights: |rd1

key 5 (276)/ id->0x00000005 rights->0x00000200 type->0x03030001
-> Hash Algo: Invalid -> Signature Algo: PKCS2.1
-> sig rights:

MSV (4) ->0x22221000
MSV Mask (4) ->0xfffff000
signer info (16) -> PK_SIG_INFO_ROM_
signature info (4) -> PKC
signature key id (4) -> 0x00434b50
-----------------------------------------------------------------
size of certificate: 2400 Bytes (0x960)
-----------------------------------------------------------------
[7" Kindle Fire HD General] craby1925:
I am much more curious, if now a true dev, not someone like me, can put together at least a custom recovery like cwm or twrp. Because if that is at least done, than we can finally make some stock based Roms.

Sent from my Fire HD with root!
[7" Kindle Fire HD General] jiffy1080:
I have seen other devices boot cycle get hijacked using charging and other methods. That is how the Xoom 2/XYBoard has received a custom recovery.

http://xdaforums.com/showthread.php?t=1941135
[7" Kindle Fire HD General] Demon520:
Thanks for the clarification and your input as well
[7" Kindle Fire HD General] mdecker2626:
Also Willing to Help

Also received my KFHD in the mail yesterday, I've been a long term dedicated root user of the Evo 4g. I rooted the KFHD yesterday after doing a lot of research to catch up and orient on this. I'm also willing to help if anything is needed.
[7" Kindle Fire HD General] Hashcode:
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.
[7" Kindle Fire HD General] jacewt:
Amazing. I just got my hd 32gb.
[7" Kindle Fire HD General] soupmagnet:
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?
[7" Kindle Fire HD General] kinfauns:
I know I didn't say that. You might want to double-check what was actually said in that PM. ;)
[7" Kindle Fire HD General] Hashcode:
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.
[7" Kindle Fire HD General] kinfauns:
Thanks for taking a crack at this... I was starting to have doubts that anybody would give it a shot.

I'm not at all familiar with your work on the Motorola side, but the way I'm understanding your overview is that the user would have to flash or otherwise modify the system partition to include your hijack. The hijack would then include some way to select an alternate rootfs image to load into RAM to provide a recovery program/interface or otherwise boot a custom ROM. It also sounds as if you're talking about keeping the stock system in place for it to be (optionally) bootable and putting the custom ROM elsewhere (separate partition). That would make it a dual-boot setup from the start.

In broad strokes, do I have most of that right? Sounds like fun times ahead. ;)
[7" Kindle Fire HD General] Hashcode:
Yep, that's the way I see it. :)
[7" Kindle Fire HD General] soupmagnet:
Obviously I don't know enough about this but hopefully you can see how I would be confused...
[7" Kindle Fire HD General] kinfauns:
Yeah, my reference to "that partition" was ambiguous, but I was talking about the boot partition. Modifying that would keep it from booting. If you read into what Hashcode is suggesting, you'll notice that he's not touching that at all.
[7" Kindle Fire HD General] Hashcode:
Correct, the only way to do custom boot.img's on a locked device is via kexec / 2nd-boot. And that's a bit complicated so it takes a while.
[7" Kindle Fire HD General] idontwanttobeanoob:
thank you

hashcode and everyone else working on this

thank you times a million for all your hard work

just got back from the army working in communications, hashcode ive followed your work for a long time now especially since the d3 and i wanna say thank you for helping me keep an up to date phone that i can communicate with the folks back home with. now that im home and have a stable work environment to start delving into actual development im hoping to contribute some of my own work.:cool:
[7" Kindle Fire HD General] fattire:
This seems to have been resolved.
[7" Kindle Fire HD General] ZilverZurfarn:
I usually don't post stupid, non contributing posts like this, but today, I'll make an exception:

WOOT! :laugh:​
[7" Kindle Fire HD General] Huuthaolove:
KINDLE FIRE 8.9 is broken bootloader

http://xdaforums.com/showthread.php?t=2009024
[Android Themes] dana4publicity:
I love soft & Dark wallpaper, Here i shear you some of my favorite collocation...

I'll try to add more & more every day.

Sample in attachment & All wallpaper + preview in my drop-box link:

--->HERE<---:​
[Android Themes] alexlinggo:
nice collection...

thank's for share bro
[AT&T, Rogers HTC One X, Telstra One XL] danny39:
Does anybody else have the rainbow effect happening to the screen protector on the Otterbox defender, also does anyone know how to fix it? (other than the baby powder trick)

Thanks in advanced

Sent from my Speak and Spell