• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[DEV] Bootloader unlock procedure and software

Search This thread

DB126

Senior Member
Oct 15, 2013
15,269
10,046
Hi Davey no I have TWRP installed I dont have safestrap haven't had it installed for quite some time. Find the whole process difficult to be honest, with no programming knowledge. I may just leave as is with TWRP installed . How do I get the kindle recognized without mounting it in TWRP. Thanks for your help
JB
Assume you can boot (any) OS:
- open Windows device manager; expand window so most/all device categories display (don't have to expand individual trees)
- attach Kindle via known good USB cable; observe what gets added
- delete all the recently added (only) devices from device manager; typically one device but occasionally two
- disconnect Kindle
- reboot both devices
- reattach Kindle; windows should find and install correct drivers

Be sure your USB cable is good and connects directly to host device (no hubs, extension cables, etc).

BTW - 1-click bootloader unlock is much easier...if it works. The path you have been taking is akin to fighting off a band of Orcs with a butter knife :)
 

Jamesblond005

Member
Dec 16, 2011
23
2
Yeah I have tried 1 click a few times without sucess will hop over to that topic , thread, see if someone can assist me further with that method thanks got the kindle recognised by following your instructions ty

Assume you can boot (any) OS:
- open Windows device manager; expand window so most/all device categories display (don't have to expand individual trees)
- attach Kindle via known good USB cable; observe what gets added
- delete all the recently added (only) devices from device manager; typically one device but occasionally two
- disconnect Kindle
- reboot both devices
- reattach Kindle; windows should find and install correct drivers

Be sure your USB cable is good and connects directly to host device (no hubs, extension cables, etc).

BTW - 1-click bootloader unlock is much easier...if it works. The path you have been taking is akin to fighting off a band of Orcs with a butter knife :)
 
Last edited:

draxie

Senior Member
Apr 20, 2014
508
610
Amazon implemented an anti-rollback method. When an older bootloader is run after the anti-rollback fuse has been set, the device will be permanently hardbricked with no way of ever being able to repair it.

Alright... so, this is what kept people from trying the obvious, but admittedly risky reflash before...
@ONYXis prevailed!!! (^;

---------- Post added at 21:50 ---------- Previous post was at 21:46 ----------

Please see my reply to his. Doing so will end you up with a permanent brick. If a solution like this was so easy, others would have done it already.

Not only arrogant, he was also dead wrong....
 

r3pwn

Inactive Recognized Developer
Jul 11, 2012
1,745
2,046
Lakeland, FL
r3pwn.com
Alright... so, this is what kept people from trying the obvious, but admittedly risky reflash before...
@ONYXis prevailed!!! (^;

---------- Post added at 21:50 ---------- Previous post was at 21:46 ----------



Not only arrogant, he was also dead wrong....

I appreciate the unwarranted hatred, but I fail to see how reporting on a hypothesis based on a large amount of users bricking their devices while trying to roll back the software on their devices is "arrogant". I admitted I was wrong. I'm glad HDX users finally have a reliable way of unlocking from any version.
 

DB126

Senior Member
Oct 15, 2013
15,269
10,046
Alright... so, this is what kept people from trying the obvious, but admittedly risky reflash before... @ONYXis prevailed!!! (^;

---------- Post added at 21:50 ---------- Previous post was at 21:46 ----------

Not only arrogant, he was also dead wrong....
Whoa there! Dredging up dusty posts to blast past guidance based on the communities best understandings at the time seems a little out of bounds. During the ensuing 18 months any number of individuals could have tried the "obvious"; seems no one wanted to sacrifice their device. Not you, not me, not @ONYXis (as previously noted) nor dozens of other 'technical' contributors. Yet bricks kept happening to unwitting users who attempted flashbacks so we all seemed satisfied with the previously presented explanation. If @r3pwn displayed arrogance by trying to prevent bricks then I am a flaming example having posted similar warnings dozens of times.
 
  • Like
Reactions: sd_shadow

draxie

Senior Member
Apr 20, 2014
508
610
I appreciate the unwarranted hatred, but I fail to see how reporting on a hypothesis based on a large amount of users bricking their devices while trying to roll back the software on their devices is "arrogant". I admitted I was wrong. I'm glad HDX users finally have a reliable way of unlocking from any version.

Frustration? Defnitely.
"Hatred"? NO WAY!!
And, I certainly don't appreciate you trying to spin it that way.

Here's the specific part that I find extremely arrogant:
If a solution like this was so easy, others would have done it already.
Granted, it's not _that_ easy. You need to also __unlock__ the bootloader you've just flashed.

BTW, as I said on the other thread: I completely agree that the assumption is plausible,
but dismissing others' ideas the way you did (and with the weight your "Respected" status
carries) **based on an unverified assumption** does come across as arrogant, in my eyes.

I also recognize and respect that you simply admit that you were wrong. That's fine.

Now, if you could help in finding a way to figure out the EMMC serial from a fastboot
prompt alone, we could also unbrick at least _some_ of those rolled-back devices;
at least those that flashed a vulnerable aboot...




---------- Post added at 10:20 ---------- Previous post was at 10:17 ----------

Whoa there! Dredging up dusty posts to blast past guidance based on the communities best understandings at the time seems a little out of bounds. During the ensuing 18 months any number of individuals could have tried the "obvious"; seems no one wanted to sacrifice their device. Not you, not me, not @ONYXis (as previously noted) nor dozens of other 'technical' contributors. Yet bricks kept happening to unwitting users who attempted flashbacks so we all seemed satisfied with the previously presented explanation. If @r3pwn displayed arrogance by trying to prevent bricks then I am a flaming example having posted similar warnings dozens of times.

First of all, I was looking for this post of mine,
when I happened to come across @r3pwn's post, and I just couldn't hold back my frustration seeing not only *what* he said,
which is quite plausible, but also **how**.

Also, if you care to check back, those posts were instrumental in establishing that "best understanding".
I've been parroting that in trying to help others, just like you, but I don't seem to recall ever having encountered
that kind of tone from you (I'm less sure about myself ;-P).
 
Last edited:

BeeWall

Senior Member
Jun 29, 2016
631
234
Can someone do a comparison of the bootloader before and after unlock? If we can figure out the difference, it may also be applicable to other devices that don't have an unlock method yet.

Sent from my Amazon Fire using XDA Labs
 

BeeWall

Senior Member
Jun 29, 2016
631
234
The bootloader doesn't change. That state is kept elsewhere (idme?).
Is there any idea of how we could figure out where? And if so, could we find the difference? Maybe comparing the important partitions (RPMB, idme, etc)? If nobody has a backup, we could use the stock recovery files, and if a partition is not in there, we could compare an unlocked device to a newer version that can't be unlocked yet.
 
Last edited:

draxie

Senior Member
Apr 20, 2014
508
610
Is there any idea of how we could figure out where? And if so, could we find the difference? Maybe comparing the important partitions (RPMB, idme, etc)? If nobody has a backup, we could use the stock recovery files, and if a partition is not in there, we could compare an unlocked device to a newer version that can't be unlocked yet.

Before spending more time on your quest, I'd like to understand
what is it that you're after and for which devices?
  1. *ALL* (still working ;^)) 3rd generation HDX tablets can be unlocked.
  2. Even if you figure out *what* changes (which is likely not that difficult),
    you'd need to be able to affect the same change in the target device,
    which is normally where you start to encounter difficulties, and the
    protection mechanisms vary (sometimes significantly) between devices.
 
  • Like
Reactions: BeeWall and DB126

BeeWall

Senior Member
Jun 29, 2016
631
234
I have an Amazon fire 5th gen. So far, I have noticed some similarities such as how to find the unlock code, and I am hoping that whatever flag triggers unlock in the hdx also works for this device.

Sent from my Amazon Fire using XDA Labs
 

draxie

Senior Member
Apr 20, 2014
508
610
I have an Amazon fire 5th gen.


If you mean this device, then I think you're best bet is to keep
asking/contributing on this thread.

So far, I have noticed some similarities such as how to find the unlock code, and I am hoping that whatever flag triggers unlock in the hdx also works for this device.

If you mean the fastboot command 'flash unlock <file>' than that "similarity"
is likely to be shared by a whole slew of other Android devices (not all, but
quite a few). BUT, keep in mind that although 'fastboot' is standard Android,
what the bootloader does when it receives that 'flash unlock' command is
what matters, and *that* might vary from one model to another.

For what it's worth, your device is based on a MediaTek chip not Qualcom,
and seems to use UBOOT (as opposed to LK) as bootloader. I don't think
anything you see here is directly applicable (but I could, of course, be wrong).

On the HDX, the unlock code is an RSA-2048 signature on the EMMC-id,
and the only reason we have a "bootloader unlock" is that early versions
of the LK-based aboot on the HDX had a signature verification bug, which
allows us to use fake signatures. Without that flaw, our best bet would be
a quantum computer that will factor 2048-bit RSA by 2030, if we're lucky. (-;


At first, this signature verification bug was used to sign custom kernels,
but after a fairly complete disassembly of the bootloader @dpeddi figured
out how the unlock code is handled (see above) and that the same signature
verification bug could be used here as well. AND, recently @ONYXis took the blue pill
and verified that once you got root flashing that old vulnerable bootloader to *any* 3rd gen
HDX is possible (if done carefully with the right preparations).

So, for starters, you'd need to (1) figure out the same (i.e. what the bootloader
does with the flash command, what's the derivation process for *your* unlock
code) and then (2) try to find a bug (or workaround) of some sort that fools
the verification in some way. GOOD LUCK! (-;

I'd also suggest you do some more research to get a better grasp of the basics.
 
Last edited:
  • Like
Reactions: BeeWall and DB126

BeeWall

Senior Member
Jun 29, 2016
631
234
If you mean this device, then I think you're best bet is to keep
asking/contributing on this thread.



If you mean the fastboot command 'flash unlock <file>' than that "similarity"
is likely to be shared by a whole slew of other Android devices (not all, but
quite a few). BUT, keep in mind that although 'fastboot' is standard Android,
what the bootloader does when it receives that 'flash unlock' command is
what matters, and *that* might vary from one model to another.

For what it's worth, your device is based on a MediaTek chip not Qualcom,
and seems to use UBOOT (as opposed to LK) as bootloader. I don't think
anything you see here is directly applicable (but I could, of course, be wrong).

On the HDX, the unlock code is an RSA-2048 signature on the EMMC-id,
and the only reason we have a "bootloader unlock" is that early versions
of the LK-based aboot on the HDX had a signature verification bug, which
allows us to use fake signatures. Without that flaw, our best bet would be
a quantum computer that will factor 2048-bit RSA by 2030, if we're lucky. (-;


At first, this signature verification bug was used to sign custom kernels,
but after a fairly complete disassembly of the bootloader @dpeddi figured
out how the unlock code is handled (see above) and that the same signature
verification bug could be used here as well. AND, recently @ONYXis took the blue pill
and verified that once you got root flashing that old vulnerable bootloader to *any* 3rd gen
HDX is possible (if done carefully with the right preparations).

So, for starters, you'd need to (1) figure out the same (i.e. what the bootloader
does with the flash command, what's the derivation process for *your* unlock
code) and then (2) try to find a bug (or workaround) of some sort that fools
the verification in some way. GOOD LUCK! (-;

I'd also suggest you do some more research to get a better grasp of the basics.
Thank you. I am a noob, and did not realize/understand differences such as LK, UBOOT, Qualcomm, MediaTek, etc. I have figured out how to find the unlock code, which is similar to hdx. I believe it is 0xssssssmm (or however long the serial is). I thought I saw an LK partition and UBOOT, but I could be wrong. I have looked at that thread, but, as I said, I don't understand much. Could you give me some tips on where to start learning/researching? Thank you!

Sent from my Amazon Fire using XDA Labs
 

draxie

Senior Member
Apr 20, 2014
508
610
Thank you. I am a noob, and did not realize/understand differences such as LK, UBOOT, Qualcomm, MediaTek, etc. I have figured out how to find the unlock code, which is similar to hdx. I believe it is 0xssssssmm (or however long the serial is). I thought I saw an LK partition and UBOOT, but I could be wrong. I have looked at that thread, but, as I said, I don't understand much. Could you give me some tips on where to start learning/researching? Thank you!

Sent from my Amazon Fire using XDA Labs

As you've undoubtedly heard many times: google is your friend.
Just keep reading threads like that, and if you read something you
don't understand, do your research. A quick lookup on google is
often a good start (and in many cases really all it takes).
 
  • Like
Reactions: BeeWall and DB126

BeeWall

Senior Member
Jun 29, 2016
631
234
As you've undoubtedly heard many times: google is your friend.
Just keep reading threads like that, and if you read something you
don't understand, do your research. A quick lookup on google is
often a good start (and in many cases really all it takes).
Do you know where idme writes to, and what it actually does? Google has yielded no useful results. Most of what i can find are the idme bootmode commands, which explain nothing.

EDIT: Found it. /proc/idme/<flag>. Even with root, it is read-only

Sent from my Amazon Fire using XDA Labs
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 39
    I get to unlock the bootloader of my kindle hdx 8.9

    Prerequisite:
    - Bootloader shipped with firmwareversion 1[34].3.1.0 <= x <= 1[34].3.2.4 (as we use the rsa bug)
    - Rooted kindle

    adb shell
    cat /sys/block/mmcblk0/device/manfid
    cat /sys/block/mmcblk0/device/serial

    create a file unlock.img with following content:
    0xmmssssssss
    where mm=manfid and ss=serial

    encrypt it with my vortox fork of signing tool at

    https://github.com/dpeddi/Cuber

    ./cuber_unlockbl --sign ./unlock.img ./unlock.signed

    connect the hdx to a linux box and do following command:

    ./fastboot -i 0x1949 devices
    ./fastboot -i 0x1949 flash unlock unlock.signed
    ./fastboot -i 0x1949 reboot

    adb shell
    idme print
    [...]
    unlock_code: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMsv9S[...]WRUFx7FaA==

    to get into fastboot mode you can press:
    standby volume+ volume- at the same time and keep pressed

    follows list of fastboot command:
    fastboot -i 0x1949 getvar product
    fastboot -i 0x1949 getvar version
    fastboot -i 0x1949 getvar kernel
    fastboot -i 0x1949 getvar serialno
    fastboot -i 0x1949 getvar production
    fastboot -i 0x1949 getvar partition-size:userdata|sytem|cache
    fastboot -i 0x1949 getvar partition-type:userdata|sytem|cache
    fastboot -i 0x1949 getvar max-download-size
    fastboot -i 0x1949 boot (still untested by me)
    fastboot -i 0x1949 verify (still untested by me)
    fastboot -i 0x1949 flash (still untested by me)
    fastboot -i 0x1949 erase (still untested by me)
    fastboot -i 0x1949 continue
    fastboot -i 0x1949 reboot
    fastboot -i 0x1949 reboot-bootloader
    fastboot -i 0x1949 oem device-info
    fastboot -i 0x1949 oem idme ? (only if unlocked)
    fastboot -i 0x1949 oem idme cl3an (untested by me but is destructive!)
    fastboot -i 0x1949 oem idme v3rsion (untested by me but seems destructive!)
    fastboot -i 0x1949 oem relock (i'm lazy to test it)
    fastboot -i 0x1949 dump (don't work with current windows implementation of fastboot that i'm using now - try this)

    you can use python only tool too :
    http://forum.xda-developers.com/kin...tools-create-unlock-img-fix-boot-img-t3050689
    http://forum.xda-developers.com/kin...e-software-t3030281/post58897784#post58897784

    Regards and thank to all (ralekdev, jcase, Hashcode, Cpasjuste, Vortox, draxie...)
    33
    Hi there,

    With so many complaints about Linux dependencies,
    I figured a Python-only version of cuber may be a good idea.
    (Windows does have Python ports, right?
    You'll still need python-gmpy2, in addition to fairly standard Python stuff.)

    So, here it comes.
    Both boot images and unlock codes are supported,
    depending on what you pass on the command line.

    For unlock codes, figure out your manfid and serial
    as explained by the OP, and use the following:
    Code:
    > python cuberHDX.py [I]mmssssssss[/I]
    Your unlock code is in '[I]mmssssssss[/I].unlock'.
    And, then do the fastboot dance from the OP.

    For boot images, the procedure is fairly similar:
    Code:
    > python cuberHDX.py [I]your-boot.img[/I]
    Your image '[I]your-boot.img[/I]' is now "signed".

    I've downloaded and tested the new version (-v2),
    and it works fine on my Apollo.

    For other that might not have understood as easily..., (its been a while since I work with anything) complete as follows. tested on HDX 7 (Thor) Rooted 13.3.1.0

    get Python 2.7 for windows and install it

    get GMPY2 for Python 2.7

    open command prompt to your ADB directory:

    Code:
    adb shell
    cat /sys/block/mmcblk0/device/manfid
    cat /sys/block/mmcblk0/device/serial

    from these 2 results you get your the code we need, insert the last 2 digits of the manfID with your serial
    following

    like this: mmssssssss

    download the attachment on the following post: http://forum.xda-developers.com/showpost.php?p=58864282&postcount=46
    Then place the file inside the attachement to C:\Python27 should be C:\Python\cuberHDX.py

    open command prompt in: C:\Python27

    replace "mmssssssss" with yours below:
    Code:
    python.exe cuberHDX.py 0xmmssssssss

    that will put a new 0xmmssssssss.UNLOCK file in the Python27 directory

    copy that file to your fastboot directory.

    on an ADB prompt type

    Code:
    adb reboot-bootloader

    then on a fastboot prompt type

    Code:
    fastboot -i 0x1949 devices
    fastboot -i 0x1949 flash unlock 0xmmssssssss.unlock
    fastboot -i 0x1949 reboot

    thats it.

    Gathered all from this thread, just a little clearer I think...
    thanks to @dpeddi, @vortox, @draxie, @ApokrifX
    8
    Python-only cuber

    Don't bother with the obsolete cuberHDX.py, please refer to this post my new post for a python-less alternative instead.

    Hi there,

    With so many complaints about Linux dependencies,
    I figured a Python-only version of cuber may be a good idea.
    (Windows does have Python ports, right?
    You'll still need python-gmpy2, in addition to fairly standard Python stuff.)

    So, here it comes.
    Both boot images and unlock codes are supported,
    depending on what you pass on the command line.

    For unlock codes, figure out your manfid and serial
    as explained by the OP, and use the following:
    Code:
    > python cuberHDX.py [I]mmssssssss[/I]
    Your unlock code is in '[I]mmssssssss[/I].unlock'.
    And, then do the fastboot dance from the OP.

    For boot images, the procedure is fairly similar:
    Code:
    > python cuberHDX.py [I]your-boot.img[/I]
    Your image '[I]your-boot.img[/I]' is now "signed".

    Finally, v3 fixes the text/binary issue and SHOULD work also on Windows.
    I cannot test as I do not have that OS..

    Oh, and thanks go to @vortox and @dpeddi for the predecessors of this script.


    UPDATE:

    For those who miss the '-c|--check' option of the original cuber,
    you can simply use the openssl command line to verify your unlock code.
    (Scroll to the right for the revelation.)
    Code:
    > python cuberHDX.py AA12345678
    Your unlock code is in 'AA12345678.unlock'.
    > openssl rsautl -verify -inkey unlock.crt -certin -in AA12345678.unlock -hexdump
    0000 - 30 78 41 41 31 32 33 34-35 36 37 38 0a 00 00 00   0xAA12345678....
    0010 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0020 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0030 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0040 - 00 00 00 00 00 00 00 00-00 00 00 93 6a d2 8e da   ............j...
    0050 - 94 30 8b 2c 38 21 09 2e-bd e1 13 7d dd e0 ba 22   .0.,8!.....}..."
    0060 - e0 1d 8d 73 8a a3 f1 ac-5b f5 3d 06 c5 95 ba 2f   ...s....[.=..../
    0070 - ab fe 86 7c 26 64 3d ee-47 84 1b cb 12 6a 42 27   ...|&d=.G....jB'
    0080 - 53 04 14 f6 a4 17 89 fc-8c b6 96 d3 10 de 21 35   S.............!5
    0090 - dc 8b c5 6e 4c ec f2 9e-c1 50 72 8a 06 ff 3b 61   ...nL....Pr...;a
    00a0 - 1a a3 52 bd c3 04 13 4c-a1 2a 8f 93 88 6b 46 cf   ..R....L.*...kF.
    00b0 - df 1f 1b f3 a1 7a d1 9d-a2 04 77 8a a3 37 14 c5   .....z....w..7..
    00c0 - 08 98 5f ac 5b d7 0f 1f-fa fe 0f e2 a4 65 5f b3   .._.[........e_.
    00d0 - f7 8b 9f bf a5 b2 28 84-39 e2 0d 03 6b 82 03 f2   ......(.9...k...
    00e0 - 25 dc f1 41 9d 27 75 6f-10 fe 93 0d c7 95 71 67   %..A.'uo......qg
    00f0 - 54 2b                                             T+
    00f5 - <SPACES/NULS>
    You can add the '-raw' flag to the end of the command line
    if you also want to see the PKCS padding string...

    For boot images, slightly more acrobatics is needed,
    for getting the hash and the signature, but it's not too bad.
    This assumes 'dd' is available on your platform.
    Code:
    [COLOR="Lime"]>[/COLOR] dd if=boot.img bs=2k of=/dev/null
    [COLOR="Red"]3634[/COLOR]+0 records in
    3634+0 records out
    7442432 bytes (7.4 MB) copied, 0.00792165 s, 940 MB/s
    [COLOR="Lime"]>[/COLOR] dd if=boot.img bs=2k skip=[COLOR="Red"]3633[/COLOR] count=256 iflag=count_bytes of=sig
    0+1 records in
    0+1 records out
    256 bytes (256 B) copied, 0.000197051 s, 1.3 MB/s
    [COLOR="Lime"]>[/COLOR] openssl rsautl -verify -inkey production.crt -certin -in sig -hexdump
    0000 - ad 84 84 25 a7 89 57 c3-8c 67 6a c3 25 5c b7 2e   ...%..W..gj.%\..
    0010 - f4 c8 90 ac a2 fb bf 36-91 3c 43 18 f4 08 c4 9e   .......6.<C.....
    0020 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0030 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0040 - 00 00 00 00 00 00 00 00-00 00 00 a4 8f 3e 09 eb   .............>..
    0050 - 65 3c 1b 3e de 2e b8 0b-6c 37 55 40 40 9e c0 dd   e<.>[email protected]@...
    0060 - f7 e0 25 7d 32 18 1b 93-dc ee 1e 9f 7c b7 1b 00   ..%}2.......|...
    0070 - d8 62 ec 67 b2 46 74 e8-7f 58 3a b7 ff 22 60 cf   .b.g.Ft..X:.."`.
    0080 - c4 27 07 83 3f d1 01 06-f6 e6 63 b7 77 5e 45 1f   .'..?.....c.w^E.
    0090 - 6e 85 2f 29 4f d0 89 70-fb d7 3c e2 da 6f e3 06   n./)O..p..<..o..
    00a0 - 5a f2 1f 9e ca aa 7d 84-24 f4 56 9d 8f 16 cf 9c   Z.....}.$.V.....
    00b0 - c1 07 74 c4 b4 1b f4 7f-04 95 cf d4 93 a1 59 e8   ..t...........Y.
    00c0 - 34 a6 aa 2a 7a 39 05 50-0f bb 2d 41 71 cf 8b 47   4..*z9.P..-Aq..G
    00d0 - 7a e5 70 3c 36 27 e0 c1-a6 14 2b 28 92 f9 d1 c3   z.p<6'....+(....
    00e0 - ac 1e 54 05 10 49 00 6d-ed f9 8a 0b f6 e7 4a 29   ..T..I.m......J)
    00f0 - 9a 74 27 10                                       .t'.
    00f5 - <SPACES/NULS>
    [COLOR="Lime"]>[/COLOR] dd if=boot.img bs=2k count=[COLOR="Red"]3633[/COLOR] | sha256sum
    3633+0 records in
    3633+0 records out
    7440384 bytes (7.4 MB) copied, 0.0493471 s, 151 MB/s
    ad848425a78957c38c676ac3255cb72ef4c890aca2fbbf36913c4318f408c49e  -
    The first 'dd' line to '/dev/null' is just to get the size in pages.
    You can do the math yourself instead. I'm just lazy...
    The other 'dd' lines use that size-1, which may not always work,
    since some images contain additional all-zero pages at the end.
    In that case you'll need to experiment with the value to skip,
    or use a hexdump utility to figure out the offset.

    Oh, and you can get all those pesky certificates from
    an ancient post of mine (speculating about a bootloader unlock).
    4
    Hello,

    steps for unlocking described by @ceyo14 here
    Some additional tips/guidance here which complements the link in the post by @D0ubl3_X. Although there are several different BL unlock guides/tools circulating I have found the one by @cey014 works best for my limited brain power.

    Unlocking is not hard but does involve utilizing tools/techniques you may not be familiar with and potentially fighting with Windows device drivers/security...especially on Win 8.1 x64. Ask targeted questions along the way; folks are generally willing to help if you have done your homework. There are no one click apks or hand holding tutorials. Grab the beverage of your choice, roll up your sleeves and plan to spend a fun evening screwing with stuff that is somewhat arcane.
    3
    Note that it *IS* possible to roll back from 3.2.x to 3.1.0
    at least, up to and including 3.2.6, which I had before TWRP came.
    The instructions for 3.2.5 and above are at the end of the post.
    The procedure is verified for 3.2.6, but f you can get root on your device,
    I suspect that this might work for 3.2.7 & 3.28 as well, but I don't know
    (since I happened to have 3.2.6 at the time).

    If you are the adventurous type and you understand what the scripts do,
    you can "extrapolate" and move to 3.2.3.2 directly (which is what I did),
    but it may be both faster and easier to move to 3.1.0 first, and then use
    the stock update from Amazon to upgrade to 3.2.3.2.

    In either case, you'll need to fetch one of these, depending on your device:

    https://kindle-fire-updates.s3.amazonaws.com/update-kindle-13.3.2.3.2_user_323001720.bin
    https://kindle-fire-updates.s3.amazonaws.com/update-kindle-14.3.2.3.2_user_323001720.bin


    Good luck!

    Amazon started including anti-rollback protection for x.3.2.7 and x.3.2.8.