Format der DRA Datei

[t-homme]

Kennt jemand den genauen Aufbau der bei Desaster/Recovery bzw. "Betankung" der Box runter geladenen Datei DRA?

Einige hier im Forum haben ja schon einiges über ihren Inhalt geschrieben.
Ich kann zwar in einem Hexdump nach einer nach Hash bzw. Signatur aussehenden hexcodierten Zeichenfolge ein paar Verzeichniseinträge wie nk.bin und boot.prf erkennen, die sich später im Root-Directory wiederfinden,
aber weiß jemand, wie sich das zusammensetzt bzw. entpackt werden kann?

Die Datei "sync" enthält ja recht offensichtlich ein paar X.509 Zertifikate, was wie auch der Name vermuten läßt, daß der korrekte Inhalt der DRA über diese verifiziert werden soll.

Weiß da schon jemand was genaueres bzw. gibt's überhaupt noch Erfolgsaussichten für die Verwendung einer irgendwie modifizierten "DRA" von einem anderen TFTP-Server?

[mce2222]

Die SYNC Datei hat mit der DRA nicht viel zu tun.  SYNC enthält nur die addresse des Bootstrap servers + Signatur über die URL + Zertifikat des Providers

Die DRA Datei selbst hat keine Signatur, aber die boot.sig hat eine für den restlichen Inhalt der noch in der boot.sig steht. Das Zertifikat zum checken dieser Signatur ist allerdings schon in der CPU und wird nicht extern bereitgestellt.

Da die boot.sig auch beim upload per TFTP geprüft wird, hat man hier eigentlich nichts gewonnen.

[robert_s]

Hatte ich schon mal geschrieben:

http://www.t-hack.com/forum/index.php?topic=18.msg92#msg92
http://www.t-hack.com/forum/index.php?topic=18.msg96#msg96

Der 8-Bytes Header besteht übrigens aus:

(HEX) AD DE 02 19 (little-endian DWORD 0x1902DEAD)
"MSFT" oder "OEM "

[t-homme]

Hatte ich schon mal geschrieben:

http://www.t-hack.com/forum/index.php?topic=18.msg92#msg92
http://www.t-hack.com/forum/index.php?topic=18.msg96#msg96

Der 8-Bytes Header besteht übrigens aus:

(HEX) AD DE 02 19 (little-endian DWORD 0x1902DEAD)
"MSFT" oder "OEM "

Danke für die Info. Das habe ich mit der Suchfunktion im Forum irgendwie doch nicht entdeckt.

Ich habe jedenfalls mal ein kleines Programm zum Rausziehen der NK.BIN aus der DRA gebaut.
Das braucht das .NET Framework 2.0, ist aber auch im Quellcode hier drin:

ftp://zerbe.homeunix.net/dra_expand.zip

Mit der mir per TFTP von discovery.iptv.t-online.de gelieferten DRA-Datei hatte ich aber nicht viel Glück.

Die hat folgenden Header:

[AD DE 02 19] MSFT
[98 02 00 00]
9d940e1b2ad886b4911d5d7fa28810b10a4618fceb7324afbdcf19172a9e3bd502976b9ce16ae9ef7f233a19c07c37a22dfe5aab203e3d8f62827e85a7b5404cc2edabe75900eeeed9b7c5aabb293ec84c4acb2fd3213988314dd30444b74738fb056827fa8433335bd7c97e7576cf1d7ae96a9423e2405a79abb0836c72e28db1b3ad7706229a6677e18c88848cdcb4f77e4d742eb1fe55077dc87702d7bfda1708703e750589a2b8c0a311610d58eaa7fc6320a8e83d6bd44c5fd3f4f616ce8a3a875b7bbf7910557e939e6282d7b1ada59e0687c51e2b9f6c79611312795449ee1444cf4373b2cc76aa3904b927855db5b7e3fe0d0a4f49f1b3f5a0caac66<LF>
nk.bin 83541f 9a9f3ae1c3f9031143a4a9e33cbf59681a70cd2b BOOTABLE
boot.prf 0 0 SELF
bootprf.bak 0 0 SELF
xtlboot.bin 0 0 SELF
xtuboot.bin 0 0 SELF

Als Beginn der NK.BIN suche ich den String "B000FF".
Dann liest mein Programm den Rest oder eine angegebene Länge in Bytes.
Weils nicht gleich geklappt hat, habe ich das mit der Längenangabe noch eingebaut,
nachdem ich vermutet habe, bei der Angabe "83541f" in dem Header oben könnte es sich um eine Dateilänge handeln.
Dieser Wert ist aber zu groß, bzw. ragt über das Ende der Datei hinaus.

Egal welche Länge ich da angebe (oder weglasse für den ganzen Rest),
ich komme bei der Analyse der rausgezogenen NK.Bin zu folgendem Ergebnis:

J:\forensic\X301T_~1\rom\DRA_EX~1\DRA_EX~1\bin\Debug>viewbin nk.bin
ViewBin... nk.bin
Image Start = 0x91E00000, length = 0x0083B20C
Done.

J:\forensic\X301T_~1\rom\DRA_EX~1\DRA_EX~1\bin\Debug>cvrtbin -r -a 91e00000 -l 83b20c -w 32 nk.bin
ViewBin... nk.bin
Image Start = 0x91E00000, length = 0x0083B20C
start 91e00000 length 00000014
start 91e00040 length 00000008
start 91e00048 length 00000004
start 91e01000 length 000613d4
start c76e4368 length 9af6b452
Warning: Record outside of ROM range, record skipped
start 79cb4e68 length 15e80de3
Warning: Record outside of ROM range, record skipped
Progress...

0%Done.

J:\forensic\X301T_~1\rom\DRA_EX~1\DRA_EX~1\bin\Debug>dumprom nk.nb0
unable to determine loading offset for nk.nb0

Hat da jemand vielleicht eine Idee, was ich da noch falsch mache?
Mit der NK.BIN, die ich auf der Platte meiner X301T vorgefunden habe, der Batch oben problemlos.

[robert_s]

Mit der mir per TFTP von discovery.iptv.t-online.de gelieferten DRA-Datei hatte ich aber nicht viel Glück.

Die hat folgenden Header:

[AD DE 02 19] MSFT

Das ist der Header, nur diese 8 Bytes!

[98 02 00 00]

Das ist die Länge der Datei BOOT.SIG (0x298 = 664 Bytes)

9d940e1b2ad886b4911d5d7fa28810b10a4618fceb7324afbdcf19172a9e3bd502976b9ce16ae9ef7f233a19c07c37a22dfe5aab203e3d8f62827e85a7b5404cc2edabe75900eeeed9b7c5aabb293ec84c4acb2fd3213988314dd30444b74738fb056827fa8433335bd7c97e7576cf1d7ae96a9423e2405a79abb0836c72e28db1b3ad7706229a6677e18c88848cdcb4f77e4d742eb1fe55077dc87702d7bfda1708703e750589a2b8c0a311610d58eaa7fc6320a8e83d6bd44c5fd3f4f616ce8a3a875b7bbf7910557e939e6282d7b1ada59e0687c51e2b9f6c79611312795449ee1444cf4373b2cc76aa3904b927855db5b7e3fe0d0a4f49f1b3f5a0caac66<LF>
nk.bin 83541f 9a9f3ae1c3f9031143a4a9e33cbf59681a70cd2b BOOTABLE
boot.prf 0 0 SELF
bootprf.bak 0 0 SELF
xtlboot.bin 0 0 SELF
xtuboot.bin 0 0 SELF

Das ist der Inhalt von BOOT.SIG. Danach folgen noch zwei weitere Dateien, siehe meinen oben verlinkten zweiten Beitrag.

Als Beginn der NK.BIN suche ich den String "B000FF".
Dann liest mein Programm den Rest oder eine angegebene Länge in Bytes.
Weils nicht gleich geklappt hat, habe ich das mit der Längenangabe noch eingebaut,
nachdem ich vermutet habe, bei der Angabe "83541f" in dem Header oben könnte es sich um eine Dateilänge handeln.
Dieser Wert ist aber zu groß, bzw. ragt über das Ende der Datei hinaus.

Dann hast Du die dra-Datei möglicherweise nicht vollständig gezogen. Sie muss aktuell 8.612.931 Bytes lang sein.

[t-homme]

Dann hast Du die dra-Datei möglicherweise nicht vollständig gezogen. Sie muss aktuell 8.612.931 Bytes lang sein.

Ja das wars! Danke für den Tipp!
Ich hatte vergessen, den TFTP Client auf BINARY zu stellen. 

Jetzt konnte ich NK.BIN problemlos entpacken, mein DRA- Zerlegetool funktioniert auch wie gewünscht und bei

nk.bin 83541f 9a9f3ae1c3f9031143a4a9e33cbf59681a70cd2b BOOTABLE

ist 83541f eindeutig die Dateilänge der nk.bin und 9a9f3ae1c3f9031143a4a9e33cbf59681a70cd2b ist laut "sha1sum" der SHA1-Hash von nk.bin

Wieder etwas schlauer, auch wenn es leider nicht dabei hilft, auch nur 1 Bit auf der Box zu verändern.

[badsurfer]

Kurze Verständnisfrage warum hilft das nicht weiter?

Aufgrund dieses Hashes?:

9d940e1b2ad886b4911d5d7fa28810b10a4618fceb7324afbdcf19172a9e3bd502976b9ce16ae9ef7f233a19c07c37a22dfe5aab203e3d8f62827e85a7b5404cc2edabe75900eeeed9b7c5aabb293ec84c4acb2fd3213988314dd30444b74738fb056827fa8433335bd7c97e7576cf1d7ae96a9423e2405a79abb0836c72e28db1b3ad7706229a6677e18c88848cdcb4f77e4d742eb1fe55077dc87702d7bfda1708703e750589a2b8c0a311610d58eaa7fc6320a8e83d6bd44c5fd3f4f616ce8a3a875b7bbf7910557e939e6282d7b1ada59e0687c51e2b9f6c79611312795449ee1444cf4373b2cc76aa3904b927855db5b7e3fe0d0a4f49f1b3f5a0caac66<LF>

Weil nen Sha-1 Hash von ner modifizierten NK.bin is ja auch nich so das Problem.

Meine Vermutung ist ja das das mehrere Hashes sind (aneinander gereiht), z.B. u.A. nen Hash von der DRA

[robert_s]

Kurze Verständnisfrage warum hilft das nicht weiter?

Aufgrund dieses Hashes?

Das ist kein Hash, sondern eine 2048-bit digitale Signatur, welche einen Hash für den restlichen Inhalt der BOOT.SIG beinhaltet. Du kannst also den Hash von NK.BIN verändern, aber dann wird die digitale Signatur ungültig - und den veränderten Inhalt kannst Du nicht neu signieren, denn der Sinn von digitalen Unterschriften ist ja gerade, dass sie fälschungssicher sein sollen. Wenn es Dir gelingt, eine 2048-bit digitale Signatur zu fälschen, dürfte es ein IT-weites Problem geben, also hoffe lieber nicht darauf

[badsurfer]

wusste nicht das es eine Signatur ist, alles klar...