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

[Tool] Signing tool for pre 3.2.4 booloaders

Search This thread
M

moonbutt74

Guest
V,



This doesn't work as the the signature contains the encrypted hash of the image which is then encrypted and compared to the calculated hash of the image. Copying the signature will result in a signature mismatch and therefore an invalid image.
okay, cool. i didn't think so either but it was worth a shot, but a question borne from that, the sum/hash is compared against the image or the kernel ? if the latter could i flip the proposed "hack" and account for size by padding ? or still nutz ?


I'm not sure about that approach. On the HDX and in LK reference code the signature shouldn't be checked if the device is unlocked.
okay neat, my other option may be to look at the grub4android option, but that will most likely be a one way ticket to brick-town.


The HDX is 32bit, too. My application is written for 32bit images. ( I should add that in the description)
The prodcert.pem shouldn't matter in an exploitable implementation. It's just there because my code is almost a 1:1 copy of the LK code, which requires certificate.
okay, you might like this then, i run debian wheezy on my tab {the underlying system, not gui, gcc-4.7, etc, needed to build mpc from source outside of repo} and compiled your tool to run native, i get the same result as on pc so it has to be a problem with the "stock" image.
is it possible to build cuber full static for portability ?

Could you send me the image?
the stock images are for the galaxy tab 4 8.0 sm-t337a [ATT]
https://www.androidfilehost.com/?w=files&flid=23541
the file names are stock-t337a-milletatt-boot.img.tar.md5 and stock-t337a-milletatt-recovery.tar.md5

The only thing you may have to change would be the modulus, but shouldn't do that. The prefix is static and doesn't need to change and the hash of image is passed using a file created by the application.
how do i determine the modulus? this is good stuff here and i want to learn it ! :good:

You said you are using a Samsung device and as far as I know Samsung likes to create their own implementation of something. Without an analysis of the bootloader I'm not able to say if they are using a LK bootloader or if it is exploitable.
these are qcom based devices so i think they are using the little kernel, and after the tab 3 which was a disaster IMO
the tab 4 line as far as the 10.1 and 8.0 are quite nice !

Thanks for you reply and for the project ! Subscribed.

m
 

vortox

Senior Member
Jan 20, 2012
50
132
V,




okay, cool. i didn't think so either but it was worth a shot, but a question borne from that, the sum/hash is compared against the image or the kernel ? if the latter could i flip the proposed "hack" and account for size by padding ? or still nutz ?

The hash is calculated from the beginning of the image to the last page of the device tree.

from bootimg.h:
Code:
+-----------------+ 
| boot header     | 1 page
+-----------------+
| kernel          | n pages  
+-----------------+
| ramdisk         | m pages  
+-----------------+
| second stage    | o pages
+-----------------+
| device tree     | p pages
+-----------------+
| signature       | 1 page
+-----------------+
Everything before signature gets hashed.

okay, you might like this then, i run debian wheezy on my tab {the underlying system, not gui, gcc-4.7, etc, needed to build mpc from source outside of repo} and compiled your tool to run native, i get the same result as on pc so it has to be a problem with the "stock" image.
is it possible to build cuber full static for portability ?

It's not the tool. Samsung modified the format of the signature. They added some magic in front. Maybe they also changed something else.
Code:
SEANDROIDENFORCE

how do i determine the modulus? this is good stuff here and i want to learn it ! :good:

I've taken the modulus directly from the certificate. It's basically the RSA cryptosystem.

Thanks for you reply and for the project ! Subscribed.

No problem.
 

vortox

Senior Member
Jan 20, 2012
50
132
Would it be helpful I can provide stock aboot, kernel, and recovery for it to be analyzed? I definitely would want this to work on my gs4 with a locked boot loader. Getting the tool running should not be an issue but needed some advice..

In the images for the Tab 4 I have seen, that Samsung uses a different format for their signatures.
Maybe I could find something in the files, but I have more important things to do at the moment.
 
  • Like
Reactions: jimyv and aromerblz

nymica

Senior Member
Aug 14, 2009
241
219
Dallas
So we can have a real recovery and flash full Roms, kernels, etc... A lot of us though are stuck with safestrap for the time being and praying someone comes up with another exploit like this for our newer bootloaders
 

draxie

Senior Member
Apr 20, 2014
508
608
The exploit

https://www.codeaurora.org/projects...tion-leads-to-signature-forgery-cve-2014-0973
The bootloader is not properly checking the number of bytes decrypted from the signature. This allows us insert to garbage bytes and create a forged signature.
A decrypted (cubed) PKCS#1 v1.5 padded signature starts with 00 01 PS 00.
PS is the padding string and consists at least of 8 FF bytes
After the start of the signature comes the 32 byte long SHA256 image hash.
So the decrypted signature should look something like this:
Code:
00 01 FF FF FF FF FF FF FF FF 00 xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xx xx .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..

Where xx is the hash and the .. are the garbage bytes.

Not that it matters, but this is not entirely accurate.
Here's what an actual signature looks like:
Code:
$ openssl rsautl -verify -inkey production.crt -certin -in sig -hexdump -raw
0000 - 00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0010 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0020 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0030 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0040 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0050 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0060 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0070 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0080 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
0090 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00a0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00b0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00c0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff   ................
00d0 - ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff 00   ................
00e0 - f6 cf b7 0b b1 fc 61 df-8b b1 fa 71 e0 34 d7 90   ......a....q.4..
00f0 - 60 03 81 0a c4 5e 1e 14-ff d9 2c 9a 7d c7 2a f8   `....^....,.}.*.
In other words, the padding string SHOULD pad
the entire unused block. That's how the length of
the actual signed data can be established.
And, since that length isn't checked, we have
the opportunity to not fill the entire block with
the padding string, but use garbage AFTER the
hash to make perfect cube.


: - - - - - - - - - - - -


Now, on to a slightly annoying issue with 'cuber'
that the attached patch fixes: the program SEGFAULTs
on Linux (due to the 'fclose' on 'NULL' , I suppose),
when 'prodcert.pem' is not in the current working
directory. Of course, removing the offending 'fclose'
might give a more polished error message, but the actual
behavior would be equally annoying. :p

I've been actually wondering WHY use that 'prodcert.pem',
when the modulus is actually hard-coded in 'signature.py'.
Well, looking a bit harder, I think I found the answer.
That hard-coded modulus is not quite the right one.
It's missing the last two bytes (or 4 hex digits: '26b9')!
Code:
$ openssl x509 -in production.crt -noout -modulus
Modulus=C88ADFC863913D4E7A63680297DB526BD5DFEC3D62CBA01B358691D5BF3C2599A7C036F70E3044BD04C8A0B4AABD6A1DAB829A787C060FD58F0ECDBDDA9CA7B08B1E8A3E1DC28E73C8B7D6F66EE39D260E0B7B4773D200C14A9167A5F5697008EA44CAE2ECBA0CC3CCF7678011EC871B0228DB3CA64F4ABC70CB954F5FE1816E4B1B7929B6625BA070D2D2E7DF5FC30B6E412C9EE77A14FAC94EF71D234AD30C29558830B690CA89601E5AD11EEE1B087203A9E66D1A9BD5CC2BC060583F362CF854F7BF780ABC6ED08FD393DA72C7F07948C438421293DA5AB261C976DA5BFD1A86470EB4B8E4DC09F692124C64090BEA03D62F8A5650D90E88CD6F785926B9
Luckily, that will not make any appreciable difference
in finding a cube[root], but it would make signature checking fail.

So, that's what the patch fixes. It hardcodes the right modulus
in 'cuber.cpp' (and in 'signature.py', for good measure), and skips
the dependency on a certificate file altogether.

Of course, most of this is totally irrelevant at this point. :crying:

What I should be doing instead is reversing 'emmc_appsboot.mbn'
to figure out what that 3rd 'Engineering' certificate in that image
is supposed to protect.

Now, that we know that (pretty much as I predicted):
  • signature-checking is broken
  • the 'Production Key' signs/verifies 'boot' and 'recovery' images
  • the 'Unlock Key' signs/verifies 'unlock' codes for bootloader unlock
I have the distinct feeling that it may be worth our while
to get us some 'Engineering' Kindles... ;)
@dpeddi: You seem to have come a long way with reversing 'aboot'.
Have you found any clues on what the 'Engineering Key' protects [yet]?
 

Attachments

  • Cuber-modulus.patch
    4.4 KB · Views: 27
  • Like
Reactions: EncryptedCurse

vortox

Senior Member
Jan 20, 2012
50
132
Not that it matters, but this is not entirely accurate.
I said I'm no an expert at cryptography. ;)
Now, on to a slightly annoying issue with 'cuber'
that the attached patch fixes: the program SEGFAULTs
on Linux (due to the 'fclose' on 'NULL' , I suppose),
when 'prodcert.pem' is not in the current working
directory. Of course, removing the offending 'fclose'
might give a more polished error message, but the actual
behavior would be equally annoying. :p
Ok, thank you.
I've been actually wondering WHY use that 'prodcert.pem',
when the modulus is actually hard-coded in 'signature.py'.
Well, looking a bit harder, I think I found the answer.
That hard-coded modulus is not quite the right one.
It's missing the last two bytes (or 4 hex digits: '26b9')!
Code:
$ openssl x509 -in production.crt -noout -modulus
Modulus=C88ADFC863913D4E7A63680297DB526BD5DFEC3D62CBA01B358691D5BF3C2599A7C036F70E3044BD04C8A0B4AABD6A1DAB829A787C060FD58F0ECDBDDA9CA7B08B1E8A3E1DC28E73C8B7D6F66EE39D260E0B7B4773D200C14A9167A5F5697008EA44CAE2ECBA0CC3CCF7678011EC871B0228DB3CA64F4ABC70CB954F5FE1816E4B1B7929B6625BA070D2D2E7DF5FC30B6E412C9EE77A14FAC94EF71D234AD30C29558830B690CA89601E5AD11EEE1B087203A9E66D1A9BD5CC2BC060583F362CF854F7BF780ABC6ED08FD393DA72C7F07948C438421293DA5AB261C976DA5BFD1A86470EB4B8E4DC09F692124C64090BEA03D62F8A5650D90E88CD6F785926B9
Luckily, that will not make any appreciable difference
in finding a cube[root], but it would make signature checking fail.
It's not hardcoded in the C++ part because I wanted to reassemble the LK signature check as closely as possible :)
Thank you for finding that mistake of mine. The tool worked, so I didn't look into that closer...
So, that's what the patch fixes. It hardcodes the right modulus
in 'cuber.cpp' (and in 'signature.py', for good measure), and skips
the dependency on a certificate file altogether.
I'll look into the patch.

What I should be doing instead is reversing 'emmc_appsboot.mbn'
to figure out what that 3rd 'Engineering' certificate in that image
is supposed to protect.
I wondered about that too.
 

dpeddi

Senior Member
Mar 10, 2007
206
133
Not that it matters, but this is not entirely accurate.
@dpeddi: You seem to have come a long way with reversing 'aboot'.
Have you found any clues on what the 'Engineering Key' protects [yet]?

Engineering key seems nothing special from the point of view of bootloader 3.1.0.

d2i_X509 is called in 3 point.

One is into the routine that check for correct unlock code (unlock cert)
Two into the image_verify routine.
If you extract the modulus of engineering certificate and modify signature.py, you should authenticate your boot/recovery.img as well like production key.

so: if fail with production key, try again with engineering key.

dpeddi
 
  • Like
Reactions: draxie

draxie

Senior Member
Apr 20, 2014
508
608
Engineering key seems nothing special from the point of view of bootloader 3.1.0.

d2i_X509 is called in 3 point.

One is into the routine that check for correct unlock code (unlock cert)
Two into the image_verify routine.
If you extract the modulus of engineering certificate and modify signature.py, you should authenticate your boot/recovery.img as well like production key.

so: if fail with production key, try again with engineering key.

dpeddi

Oh, I see. Thanks for checking, anyway!
I suppose, the bootloader could -at least, theoretically- set some flags
differently if it could tell that the engineering key was used for signing.

Unfortunately, our forged signatures do not depend on the actual key.
A perfect cube is a perfect cube, and the modulus is *always* larger than
0x0001FF.... So, whichever key the bootloader tries first will succeed.

Which reminds me that I should post my new Python-only gmpy2-free
modulus-independent version of cuber. ;) :p
Hopefully, I'll have time to test before posting tomorrow.
 
  • Like
Reactions: EncryptedCurse

jaw20

Senior Member
Nov 16, 2013
62
120
@vortox What was the process that you used to extract the key from boot.img? There are people currently trying to port cuber to the s4, and are wondering this question. Can we also keep this to pm?
 

vortox

Senior Member
Jan 20, 2012
50
132
@vortox What was the process that you used to extract the key from boot.img? There are people currently trying to port cuber to the s4, and are wondering this question. Can we also keep this to pm?

I don't have any key used to sign the images. The only thing I've got is just the certificate, which I extracted directly from the binary aboot.img. The certificate is to verify the the generated File. From the certificate I got the modulus.

On the Topic Samsung I'm gonna quote myself from another thread:
The modulus shouldn't matter in most cases. It's just an upper bound for the generated sigature. To use my tool for the exploit it's more important to understand the format of the signature. The samsung ones i've seen are different for the reference implementation.
Example from the Galaxy Tab 4, I think it's similar to the S4:
No. As I said it's necessary to understand the format of the signature.
In the reference implementation the signature is is simply 256 bytes long and PKCS#1 v1.5 padded.
On this device however it's this way:
  • First some 32 byte magic number
    Code:
     SEANDROIDENFORCE
  • then 256 bytes, maybe the encrypted signature (?)
  • and at the end 224 bytes that looks like a PKCS#1 v1.5 padded decrypted signature
This makes 512 bytes and is incompatible with my tool!
 
Last edited:

jaw20

Senior Member
Nov 16, 2013
62
120
@vortox

From looking at this info, would the s4 still be vulnerable?

Code:
PAD_BYTE_1 = 255 # Padding byte 1s
PAD_BYTE_0 = 0 # Padding byte 0s
SHA256_SIGNATURE_SIZE = 256 # Support SHA256
MAX_NUM_ROOT_CERTS = 4 # Maximum number of OEM root certificates
BOOT_IMG_HDR_SIZE = 40 # sizeof(mi_boot_image_header_type)
BOOT_SBL_HDR_SIZE = 80 # sizeof(sbl_header)
BOOT_HEADER_LENGTH = 20 # Boot Header Number of Elements
SBL_HEADER_LENGTH = 20 # SBL Header Number of Elements
FLASH_PARTI_VERSION = 3 # Flash Partition Version Number

# Magic numbers filled in for boot headers
FLASH_CODE_WORD = 0x844BDCD1
UNIFIED_BOOT_COOKIE_MAGIC_NUMBER = 0x33836685
MAGIC_NUM = 0x73D71034
AUTODETECT_PAGE_SIZE_MAGIC_NUM = 0x7D0B435A


Sent from my SCH-I545 using XDA Free mobile app
 
Last edited:

vortox

Senior Member
Jan 20, 2012
50
132
@vortox

From looking at this info, would the s4 still be vulnerable?

Code:
PAD_BYTE_1 = 255 # Padding byte 1s
PAD_BYTE_0 = 0 # Padding byte 0s
SHA256_SIGNATURE_SIZE = 256 # Support SHA256
MAX_NUM_ROOT_CERTS = 4 # Maximum number of OEM root certificates
BOOT_IMG_HDR_SIZE = 40 # sizeof(mi_boot_image_header_type)
BOOT_SBL_HDR_SIZE = 80 # sizeof(sbl_header)
BOOT_HEADER_LENGTH = 20 # Boot Header Number of Elements
SBL_HEADER_LENGTH = 20 # SBL Header Number of Elements
FLASH_PARTI_VERSION = 3 # Flash Partition Version Number

# Magic numbers filled in for boot headers
FLASH_CODE_WORD = 0x844BDCD1
UNIFIED_BOOT_COOKIE_MAGIC_NUMBER = 0x33836685
MAGIC_NUM = 0x73D71034
AUTODETECT_PAGE_SIZE_MAGIC_NUM = 0x7D0B435A


Sent from my SCH-I545 using XDA Free mobile app

To determine vulnurability it's necessary to analyse the bootloader. There is a chance it is exploitable, but I can't guarantee anything.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 27
    I am proud to present you my image signing tool called Cuber.
    The name is an abbreviation of Cube Root finder. This is basically what the tool does.

    About

    This is a tool that checks and signs recovery/boot images for Little Kernel bootloaders missing the patch for for CVE-2014-0973.

    Who is vulnurable?

    Kindle Fire HDX tablets with firmware versions older than 3.2.4. On 3.2.4 it is NOT working.
    Probably many devices using pre 13 June 2014 Little Kernel bootloaders. (no guarantees)

    Requirements on an Ubuntu system:

    Code:
    gcc
    libmpc-dev
    libmpfr-dev
    libgmp3-dev
    libssl-dev
    python
    python-pip

    Also the following python package is required:
    Code:
    gmpy2
    install it using pip:
    Code:
    sudo pip install gmpy2

    Installation

    Download the source code from https://github.com/Verteo/Cuber to your desired folder, go to the folder and run make.

    Usage

    Code:
    ./cuber -check path/to/image.img
    checks if the image would pass the signature verification

    Code:
    ./cuber -sign path/to/input/image.img path/to/output/image.img
    creates a signature for the given image and creates a new signed at the specified location

    The files prodcert.pem and signature.py are required by the application to work

    Why python?

    It is easier to handle bignums in python than in c++.

    The exploit

    https://www.codeaurora.org/projects...tion-leads-to-signature-forgery-cve-2014-0973
    The bootloader is not properly checking the number of bytes decrypted from the signature. This allows us insert to garbage bytes and create a forged signature.
    A decrypted (cubed) PKCS#1 v1.5 padded signature starts with 00 01 PS 00.
    PS is the padding string and consists at least of 8 FF bytes
    After the start of the signature comes the 32 byte long SHA256 image hash.
    So the decrypted signature should look something like this:
    Code:
    00 01 FF FF FF FF FF FF FF FF 00 xx xx xx xx xx
    xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
    xx xx xx xx xx xx xx xx xx xx xx .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..

    Where xx is the hash and the .. are the garbage bytes.
    The garbage byte can have an arbitrary value. We use them to create a perfect cube root.

    Example

    Hash of example image:

    Code:
    A9 07 1C A3 31 43 16 F7 2E 9A FF B3 31 46 A6 EC 60 6E DE 42 45 9E 4C 9B 6B 5F B0 E1 97 1C 33 85

    Desired cubed signature:

    Code:
    00 01 FF FF FF FF FF FF FF FF 00 A9 07 1C A3 31 
    43 16 F7 2E 9A FF B3 31 46 A6 EC 60 6E DE 42 45
    9E 4C 9B 6B 5F B0 E1 97 1C 33 85 .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
    .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..

    Generated signature:

    Code:
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 32 CB FD 4A 7A
    DC 79 05 58 41 75 78 07 60 1D 4F D5 09 9A 22 ED
    4A F3 B3 46 62 94 03 A0 78 BF AE E1 FF 07 49 B4
    98 C9 C7 F6 96 A1 66 E1 3A D0 8A 97 9D 82 4D 64
    08 4E 91 B1 D3 F8 EB 97 81 57 92 97 D3 F2 E5 D5
    6F A4 6C DC 91 79 11 A4 9F 23 83 4E A4 84 20 C0

    Generated signature cubed:

    Code:
    00 01 FF FF FF FF FF FF FF FF 00 A9 07 1C A3 31 
    43 16 F7 2E 9A FF B3 31 46 A6 EC 60 6E DE 42 45
    9E 4C 9B 6B 5F B0 E1 97 1C 33 85 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 8D C2 E5 F5 65 19 0A BA 69 BA
    14 29 BE 83 F4 2E 61 04 3E 1E 59 79 3C C6 D6 D8
    D0 59 D1 46 E4 D4 86 B8 D4 A0 C1 2F 3A 4C 72 F7
    F4 14 E7 CF CE 3F 5D A3 53 25 D6 7B 7B 83 AF 66
    B8 42 A7 06 79 7C 31 69 51 43 F6 83 B2 29 65 81
    F5 B0 9D 93 77 6B BA 83 52 C0 F0 68 93 AF 65 9E
    19 F2 EC 9D 9A 76 90 30 15 5F F5 B5 88 EB 89 FE
    CB DC 3A 4E D7 71 32 E3 10 FF 39 C0 C0 73 47 71
    A2 C4 07 7A 3C E2 F7 96 68 A3 C8 35 40 33 02 A5
    AA 4E CB BB AC 56 DB 98 F2 50 76 BD A7 82 6E C3
    AC 34 F4 E9 E7 87 99 43 B4 6E 94 67 F6 6C 00 00

    As you may notice this is valid signature.

    Disclaimer

    I'm not an expert at cryptography, my statements may be false or incomplete.
    2
    I'm not sure if this is an isolated problem, but I'm getting errors when I try to compile:
    Code:
    [email protected]:/Cuber-master# make
    g++ -Iinclude Cuber.cpp -o Cuber -lcrypto
    In file included from Cuber.h:7:0,
                     from Cuber.cpp:1:
    bootimg.h:108:5: error: ‘uint32_t’ does not name a type
         uint32_t insn;
         ^
    bootimg.h:109:5: error: ‘uint32_t’ does not name a type
         uint32_t res1;
         ^
    bootimg.h:110:5: error: ‘uint64_t’ does not name a type
         uint64_t text_offset;
         ^
    bootimg.h:111:5: error: ‘uint64_t’ does not name a type
         uint64_t res2;
         ^
    bootimg.h:112:5: error: ‘uint64_t’ does not name a type
         uint64_t res3;
         ^
    bootimg.h:113:5: error: ‘uint64_t’ does not name a type
         uint64_t res4;
         ^
    bootimg.h:114:5: error: ‘uint64_t’ does not name a type
         uint64_t res5;
         ^
    bootimg.h:115:5: error: ‘uint64_t’ does not name a type
         uint64_t res6;
         ^
    bootimg.h:116:5: error: ‘uint32_t’ does not name a type
         uint32_t magic_64;
         ^
    bootimg.h:117:5: error: ‘uint32_t’ does not name a type
         uint32_t res7;
         ^
    Cuber.cpp: In function ‘int main(int, char**)’:
    Cuber.cpp:18:30: error: ‘strcmp’ was not declared in this scope
      if (strcmp(argv[1], "-check") == 0 && argc == 3){
                                  ^
    Cuber.cpp:22:29: error: ‘strcmp’ was not declared in this scope
      if (strcmp(argv[1], "-sign") == 0 && argc == 4) {
                                 ^
    Cuber.cpp: In function ‘int check_image(char*)’:
    Cuber.cpp:77:41: error: ‘memcpy’ was not declared in this scope
      memcpy(hdr, image, sizeof(boot_img_hdr));
                                             ^
    Cuber.cpp:83:45: error: ‘memcmp’ was not declared in this scope
      if (memcmp((char*)hdr->magic, "ANDROID!", 8) != 0){
                                                 ^
    Cuber.cpp: In function ‘int sign_image(char*, char*)’:
    Cuber.cpp:168:45: error: ‘memcmp’ was not declared in this scope
      if (memcmp((char*)hdr->magic, "ANDROID!", 8) != 0){
                                                 ^
    Cuber.cpp:235:37: error: ‘memset’ was not declared in this scope
      memset(signature, 0, SIGNATURE_SIZE);
                                         ^
    Cuber.cpp:249:62: error: ‘memcpy’ was not declared in this scope
        memcpy(image + imagesize_actual, signature, SIGNATURE_SIZE);
                                                                  ^
    Cuber.cpp: In function ‘int verify_image(unsigned char*, unsigned char*, unsigned int)’:
    Cuber.cpp:359:42: error: ‘memcmp’ was not declared in this scope
      if (memcmp(plain_text, digest, hash_size) != 0) {
                                              ^
    Cuber.cpp: In function ‘int create_signature(unsigned char*, unsigned char*)’:
    Cuber.cpp:450:48: error: ‘memcpy’ was not declared in this scope
      memcpy(outputbuffer + offset, buffer, filesize);
                                                    ^
    Makefile:2: recipe for target 'all' failed
    make: *** [all] Error 1
    2
    What are the chances this works on Amazon's Fire phone? I just picked one up dirt cheap and I would love to flash CM on it.

    Maybe an unsigned fire phone boot image might be signed with this?

    Sent from my GT-i9100 running CM11

    Yes you can sign an image. You just need a vulnurable bootloader. The exploit was publicly fixed on 13 June and the first patched bootloader for the hdx tablets ( .3.2.4) was compiled on 20 June.
    2
    Would it be helpful I can provide stock aboot, kernel, and recovery for it to be analyzed? I definitely would want this to work on my gs4 with a locked boot loader. Getting the tool running should not be an issue but needed some advice..

    In the images for the Tab 4 I have seen, that Samsung uses a different format for their signatures.
    Maybe I could find something in the files, but I have more important things to do at the moment.
    1
    @vortox: I submitted a pull request with the help of @TheReverend403, which notably fixes the errors I was facing above and some more.

    https://github.com/Verteo/Cuber/pull/2