Vraag:
Versla rsa hash-verificatie
Remko
2016-03-24 00:14:13 UTC
view on stackexchange narkive permalink

Ik analyseer een embedded systeem met QNX op armle, uname -a identificeert het als: 

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

Firmware-updates worden geleverd met een bestand met de naam metainfo2.txt dat altijd eindigt met een kenmerkend blok, bijvoorbeeld: 

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

Dit lijkt erop dat het een RSA-codering is en wordt gebruikt om te bepalen of de bestandsinhoud is gewijzigd. Ik denk dat het een hash is van een bepaalde sectie van het bestand: MetafileChecksum = "ec5afd6459c3579ebed8841cc41fe17bb61b814d"

Ik heb een map met publieke sleutels gevonden die een submap heeft naam MetainfoKey en bevat waarschijnlijk de publieke sleutel, een bestand van 288 bytes: 

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

Mijn doel is om metainfo2.txt te kunnen wijzigen en een mogelijke methode zou kunnen zijn om de openbare sleutel te vervangen door een nieuwe, maar ik moet begrijpen hoe de handtekeningsectie wordt gebruikt om de inhoud van het bestand. Ik ben op zoek naar antwoorden of aanwijzingen om dit te bereiken ...

Drie antwoorden:
Peter Andersson
2016-03-24 12:54:43 UTC
view on stackexchange narkive permalink

Uw vermoedens zijn correct. Het toevoegen van alle getallen in de handtekening velden het nummer krijg je

en i> = 0xa73e111de512e09bad2dc08eff685a384fc032192a20fd1e242ad64af5b509a76a7432f754aff0d6b74a7ec2072cbb11e91f68f569508b77712d1869edd6d0b9923eb77ba815dba8e44d5e09412cdf2e830518f3b38d48df892a3a0c65cc67f109e5e0f5f06ce0376d032ab21051510f3dab7f75fcdf54a96d8aa7f3c617f76d

die te groot is om te passen met een modulus van

n i> = 0x830ACD6556FC2FB47B1B674312E34E7A0AAD1EDFBA7EB279D9513ADB10166148131BBA9C852AB701914916656294616BB1A9B8F8462EBC206DE57F53AFEF000053AB8E4F6329BF00B0ED45E8E920678EF67AF8BCCB7B4DCF880159BBCBF1B104D4A1C05770AAD738E8BD9A284E94995CB79649285AC4049C6B578FC54F746AC9

, zodat we een modulus van zult gebruiken

n i> = 0xC0F389EEC7B66C9DC736508FF88AEB1FB113942EAD020814D08D29E868F14B2086BCD7DDCCBA7559F999E76D24619660BBE17434DA59988087F2A99CD465B1FF423522B78CB0DE463A669613D356DFA9E86E0E2E0B6DAB5DE89131C5A0727AEAB1767278AB101DCD9C3CFC1026705C1DAB3BF53BF50AFAFB3F52DA2CEB0BEE57

het nemen van de signature en i> tot de macht van 3 modulus n i> we wind met de volgende waarde

0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a050004145e3246e50a4dad079a61f99fa3297c01d802e038

Dit is een standaard handtekening formaat. De 0x1ffff ... 00 is aan het opvullen. De 3021 ... is een ASN.1-gecodeerde structuur.

Ontleed dat met OpenSSL

openssl.exe asn1parse -inform DER -dump -i 

 0: d = 0 hl = 2 l = 33 nadelen: SEQUENCE 2: d = 1 hl = 2 l = 9 nadelen: 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

Wat ons vertelt dat de handtekening is gebaseerd op een SHA1-hash. Om de gegevens te wijzigen die door deze sleutels zijn ondertekend, moet u uw eigen 1024-bits RSA-sleutel genereren, de c0 ... -sleutel vervangen door uw eigen openbare sleutel, de gegevens wijzigen, de hash in de bovenstaande gegevens vervangen en die gegevens ondertekenen met uw privésleutel.

Heel erg bedankt Peter! Als volgende stap probeer ik te begrijpen hoe het apparaat de handtekening verifieert en verifieert dat de ondertekende hash inderdaad de `MetafileChecksum` is. Enige tips over hoe je dat moet doen?
MetafileChecksum is waarschijnlijk slechts een SHA1-hash van een bestand. Ik zou proberen kandidaatbestanden te SHA1 totdat je een match hebt gevonden. Hopelijk heb je geluk.
Ja, ik weet hoe ik `MetafileChecksum` moet berekenen, het is sha1 van het bestand zelf exclusief de sectie` handtekening` en de regel `MetafileChecksum`. Ik begrijp niet (waarschijnlijk vanwege een gebrek aan rsa-kennis) hoe MetafileChecksum te decoderen met behulp van de openbare sleutel om dezelfde waarde te verkrijgen als `MetafileChecksum`. Als dat eenmaal werkt, kan ik proberen de openbare sleutel te vervangen.
U hoeft de MetafileChecksum niet echt te decoderen. Het is een hash, dus het kan niet als zodanig worden gedecodeerd. Wijzig gewoon de delen van het bestand die u moet wijzigen, herbereken de SHA1 en update MetafileChecksum. U moet echter de gegevens vinden die hashes naar 5e 32 ... e0 38. Omdat dat de gegevens zijn die worden beschermd door het handtekeningblok.
pcbbc
2017-09-25 18:09:29 UTC
view on stackexchange narkive permalink

Zoals u al weet is MetafileChecksum = "ec5afd6459c3579ebed8841cc41fe17bb61b814d" de SHA1-hash van het oorspronkelijke metainfo2.txt -bestand, voordat de regel MetafileChecksum wordt toegevoegd en laatste [Signature] -blok.

Zoals Peter Anderson opmerkt, zijn de eerste 128 bytes van uw openbare sleutelbestand de RSA openbare / privé-sleutelmodulus ( n = C0 F3 .. EE 57 ). Wat in combinatie met de publieke exponent ( e = 00 00 .. 00 03 ) in de volgende 32 bytes van het bestand ons de openbare RSA-sleutel (n, e) oplevert . Past men de gegevens in de [Signature] blok levert: 

  1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a050004145e3246e50a4dad079a61f99fa3297c01d802e038

Een standaard ASN.1 signatuurstructuur bevattende de SHA1-hash 5e3246e50a4dad079a61f99fa3297c01d802e038.

Je zult zien dat dit de SHA1-hash is van metainfo2.txt nadat je hebt toegevoegd het MetafileChecksum maar voordat het [Signature] -blok wordt toegevoegd.

Je kunt je ook afvragen wat de resterende 128 bytes (83 0A .. 6A C9) in het sleutelbestand vertegenwoordigen? Nou, als je decoderen deze met dezelfde publieke sleutel, krijg je: 

  1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff003021300906052b0e03021a05000414c9b809bea9c9d13a87f7ef2212d9d03281da7020

Ook een ASN.1 handtekening structuur die de SHA1 hash c9b809bea9c9d13a87f7ef2212d9d03281da7020 . En je zult zien dat dit de SHA1 is van de eerste 128 + 32 = 160 bytes van het sleutelbestand met de publieke sleutel (n, e).

Helaas brengt dit ons niet in de buurt van het kunnen ondertekenen van metainfo2.txt -bestanden, omdat we de exponent van de privésleutel (d) niet kennen. Maar als u de sleutels vervangt door uw eigen sleutels, weet u nu tenminste hoe u het MetainfoKey -bestand volledig kunt vullen en ook hoe u een metainfo2.txt met uw eigen sleutel kunt ondertekenen. privésleutel.

Ja, ik kwam tot dezelfde conclusie
Congo
2017-11-05 14:06:12 UTC
view on stackexchange narkive permalink

Na enig onderzoek kwam ik tot de conclusie dat we niet zomaar de sleutels kunnen veranderen. zoals je al weet zijn ze allemaal ondertekend, en hoewel de tekensleutel de MIB-High_MI_public lijkt te zijn, is het eigenlijk een sleutel die zich in het NOR flash OTP-gebied bevindt In ons geval is het hetzelfde als de openbare sleutel, maar dat kunnen we niet veranderen. MIBRoot controleer dit voordat het de sleutels gebruikt, gevonden in het persistente gebied. Tenzij je de flash-chip verandert, kun je je eigen sleutels niet gebruiken, dus het is gewoon niet de moeite waard :)

Groeten.



ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...