[Tool] Signing tool for pre 3.2.4 booloaders

moonbutt74

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 · Jan 20, 2012 50 132 0

moonbutt74 said:
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.

aromerblz · Sep 23, 2012 479 111 73 my backyard Samsung Galaxy Note 9

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..

vortox · Jan 20, 2012 50 132 0

aromerblz said:
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.

aromerblz · Sep 23, 2012 479 111 73 my backyard Samsung Galaxy Note 9

vortox said:
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.

Understood, well any help or guidance would be appreciated at this time.

gabrielgallo90 · Jul 16, 2014 29 1 0

aromerblz said:
Understood, well any help or guidance would be appreciated at this time.

Hello , excuse my ignorance, but ... what good is this tool?

nymica · Aug 14, 2009 241 219 0 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 · Apr 20, 2014 493 596 123

vortox said:
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.

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]?

vortox · Jan 20, 2012 50 132 0

draxie said:
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.

Ok, thank you.

Code:
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 · Mar 10, 2007 205 133 63

draxie said:
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

draxie · Apr 20, 2014 493 596 123

dpeddi said:
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.

Hopefully, I'll have time to test before posting tomorrow.

draxie · Apr 20, 2014 493 596 123

Tomorrow finally came...

Here's my Python-only cuber without gmpy2.

jaw20 · Nov 16, 2013 62 120 0

@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 · May 21, 2015

jaw20 said:
@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:

vortox said:
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:

vortox said:
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!

jaw20 · May 25, 2015

@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

vortox · Jan 20, 2012 50 132 0

jaw20 said:

@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.

rootdefyxt320 · Oct 4, 2012 488 440 0 Sydney, NSW

How to adapt it to Sony aboot dated March 2014? I wanted to try it on my locked bootloader device.

draxie · Apr 20, 2014 493 596 123

Look ma no Python

I've just posted my pure C implementation of cuber using OpenSSL's BigNum library.

[Tool] Signing tool for pre 3.2.4 booloaders

moonbutt74

Guest

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts