Defeat rsa hash verification

Question

I am analysing an embedded system running QNX on armle, uname -a identifies it as:

QNX mmx 6.5.0 2012/06/20-13:49:13EDT nVidia_Tegra2(T20)_Devlite_Boards armle

Firmware updates come with a file called metainfo2.txt which always ends with a signature block, eg:

[Signature]
signature1 = "a73e111de512e09bad2dc08eff685a38"
signature2 = "4fc032192a20fd1e242ad64af5b509a7"
signature3 = "6a7432f754aff0d6b74a7ec2072cbb11"
signature4 = "e91f68f569508b77712d1869edd6d0b9"
signature5 = "923eb77ba815dba8e44d5e09412cdf2e"
signature6 = "830518f3b38d48df892a3a0c65cc67f1"
signature7 = "09e5e0f5f06ce0376d032ab21051510f"
signature8 = "3dab7f75fcdf54a96d8aa7f3c617f76d"

This looks like it's a RSA encryption and is used to determine if the file contents were changed. I think it's a hash of a particular section of the file: MetafileChecksum = "ec5afd6459c3579ebed8841cc41fe17bb61b814d"

I found a folder with public keys which has a subfolder name MetainfoKey and contains likely the public key, a 288 byte file:

C0 F3 89 EE C7 B6 6C 9D C7 36 50 8F F8 8A EB 1F
B1 13 94 2E AD 02 08 14 D0 8D 29 E8 68 F1 4B 20
86 BC D7 DD CC BA 75 59 F9 99 E7 6D 24 61 96 60
BB E1 74 34 DA 59 98 80 87 F2 A9 9C D4 65 B1 FF
42 35 22 B7 8C B0 DE 46 3A 66 96 13 D3 56 DF A9
E8 6E 0E 2E 0B 6D AB 5D E8 91 31 C5 A0 72 7A EA
B1 76 72 78 AB 10 1D CD 9C 3C FC 10 26 70 5C 1D
AB 3B F5 3B F5 0A FA FB 3F 52 DA 2C EB 0B EE 57
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 03
83 0A CD 65 56 FC 2F B4 7B 1B 67 43 12 E3 4E 7A
0A AD 1E DF BA 7E B2 79 D9 51 3A DB 10 16 61 48
13 1B BA 9C 85 2A B7 01 91 49 16 65 62 94 61 6B
B1 A9 B8 F8 46 2E BC 20 6D E5 7F 53 AF EF 00 00
53 AB 8E 4F 63 29 BF 00 B0 ED 45 E8 E9 20 67 8E
F6 7A F8 BC CB 7B 4D CF 88 01 59 BB CB F1 B1 04
D4 A1 C0 57 70 AA D7 38 E8 BD 9A 28 4E 94 99 5C
B7 96 49 28 5A C4 04 9C 6B 57 8F C5 4F 74 6A C9

My objective is to be able to change metainfo2.txt and a possible method could be to replace the public key with a new one but I need to understand how the signature section is used to verify the file contents. I am looking for answer or pointers on how to achieve this...

Answer 1

Your hunches are correct. Appending all the numbers in the signature fields you get the number

s = 0xa73e111de512e09bad2dc08eff685a384fc032192a20fd1e242ad64af5b509a76a7432f754aff0d6b74a7ec2072cbb11e91f68f569508b77712d1869edd6d0b9923eb77ba815dba8e44d5e09412cdf2e830518f3b38d48df892a3a0c65cc67f109e5e0f5f06ce0376d032ab21051510f3dab7f75fcdf54a96d8aa7f3c617f76d

which is too large to fit with a modulus of

n = 0x830ACD6556FC2FB47B1B674312E34E7A0AAD1EDFBA7EB279D9513ADB10166148131BBA9C852AB701914916656294616BB1A9B8F8462EBC206DE57F53AFEF000053AB8E4F6329BF00B0ED45E8E920678EF67AF8BCCB7B4DCF880159BBCBF1B104D4A1C05770AAD738E8BD9A284E94995CB79649285AC4049C6B578FC54F746AC9

so we'll use a modulus of

n = 0xC0F389EEC7B66C9DC736508FF88AEB1FB113942EAD020814D08D29E868F14B2086BCD7DDCCBA7559F999E76D24619660BBE17434DA59988087F2A99CD465B1FF423522B78CB0DE463A669613D356DFA9E86E0E2E0B6DAB5DE89131C5A0727AEAB1767278AB101DCD9C3CFC1026705C1DAB3BF53BF50AFAFB3F52DA2CEB0BEE57

taking the signature s raised to the power of 3 modulus n we wind up with the following value

0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a050004145e3246e50a4dad079a61f99fa3297c01d802e038

This is a standard signature format. The 0x1ffff...00 is padding. The 3021... is an ASN.1 encoded structure.

Parse that using OpenSSL

openssl.exe asn1parse -inform DER -dump -i

    0:d=0  hl=2 l=  33 cons: SEQUENCE
    2:d=1  hl=2 l=   9 cons:  SEQUENCE
    4:d=2  hl=2 l=   5 prim:   OBJECT            :sha1
   11:d=2  hl=2 l=   0 prim:   NULL
   13:d=1  hl=2 l=  20 prim:  OCTET STRING
      0000 - 5e 32 46 e5 0a 4d ad 07-9a 61 f9 9f a3 29 7c 01   ^2F..M...a...)|.
      0010 - d8 02 e0 38                                       ...8

Which tells us that the signature is based off of a SHA1 hash. To change the data signed by these keys, you'd need to generate your own 1024 bit RSA key replace the c0... key with your own public key, change the data, replace the hash in the data above and sign that data using your private key.

Answer 2

As you already know MetafileChecksum = "ec5afd6459c3579ebed8841cc41fe17bb61b814d" is the SHA1 hash of the initial metainfo2.txt file, before adding the MetafileChecksum line and final [Signature] block.

As Peter Anderson points out, the first 128 bytes of your public key file are the RSA public/private key modulus (n = C0 F3 .. EE 57). Which when combined with the public exponent (e = 00 00 .. 00 03) in the next 32 bytes of the file yields us the RSA public key (n, e). Applying that to the data in your [Signature] block yields:

1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffff003021300906052b0e03021a050004145e3246e50a4dad079a61f99fa3297c01d802e038

A standard ASN.1 signature structure containing the SHA1 hash 5e3246e50a4dad079a61f99fa3297c01d802e038.

You'll find that's the SHA1 hash of metainfo2.txt after you've added the MetafileChecksum but before appending the [Signature] block.

Also, you may be left wondering what the remaining 128 bytes (83 0A .. 6A C9) in the key file represent? Well, if you decrypt these using the same public key, you'll get:

1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffff003021300906052b0e03021a05000414c9b809bea9c9d13a87f7ef2212d9d03281da7020

Again a ASN.1 signature structure containing the SHA1 hash c9b809bea9c9d13a87f7ef2212d9d03281da7020. And you'll find that's the SHA1 of first 128+32=160 bytes of the key file containing the public key (n, e).

Unfortunately none of this gets us any close to being able to sign metainfo2.txt files, as we don't know the private key exponent (d). But if you are replacing the keys with your own, at least you now know how to fully populate the MetainfoKey file, and also how to sign a metainfo2.txt with your own private key.

Answer 3

After some research i came to conclusion that we cannot simply change the keys. As you already know they are all signed, and although the sign key looks to be the MIB-High_MI_public its actually a key that's in the NOR flash OTP area. In our case it happens to be the same is the public key but we cant change that. MIBRoot check this before it uses the keys found the the persist area. Unless you change the flash chip you cant use your own keys so it just not worth the effort :)

Regards.