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:

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


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


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.

  • Thanks a lot Peter! As next step I am trying to understand how device verifies the signature and verify that the signed hash is indeed the MetafileChecksum. Any hints on how to do that? – Remko Mar 24 '16 at 8:32
  • MetafileChecksum is probably just a SHA1 hash of some file. I would try to SHA1 candidate files until you hit a match. Hopefully you get lucky. – Peter Andersson Mar 24 '16 at 8:34
  • Yes I know how to calculate MetafileChecksum, it's sha1 of the file itsself excluding signature section and MetafileChecksum line. I don't understand (likely due to lack of rsa knowledge) how to decrypt MetafileChecksum using the public key to obtain same value as MetafileChecksum. Once I have that working I can try to replace public key.. – Remko Mar 24 '16 at 8:37
  • You don't really need to decrypt the MetafileChecksum. It's a hash so it can't be decrypted as such. Just modify the parts of the file you need to modify, recalculate the SHA1 and update MetafileChecksum. You need to find the data which hashes to 5e 32 ... e0 38 though. Since that's the data protected by the signature block. – Peter Andersson Mar 24 '16 at 8:40

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:


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:


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.

  • Yes I came to the same conclusion – Remko Sep 25 '17 at 15:15

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 :)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.