28. Oct 2024, 06:24

TFTP ansatz

Started by asgard, 19. Jan 2008, 15:47

previous topic - next topic
Go Down

robert_s

#45
20. Jan 2008, 11:23 Last Edit: 20. Jan 2008, 13:03 by robert_s

das scheint zu funktionieren...nach dem er das file hat, kommen die 2 Zahnräder von der desaster-recovery...siehe foto...


Jetzt probier' doch mal, mit einem Hex-Editor die Datei zu verändern, um zu sehen, ob die Signatur wirklich überprüft wird, und ob man das vielleicht umgehen kann. Probier' mal folgende Veränderungen:

1. Den Dateinamen "bootprf.bak" ab Offset 0x262 zu verändern, z.B. das erste "b" in ein "B" verwandeln (also 0x262: 0x62 -> 0x42)
2. Aus der Kennung "MSFT" ab Offset 4 die Kennung "OEM " (mit Leerzeichen am Ende) zu machen.
3. Die Kombination von 1. und 2.

Wenn alle drei Varianten nur zum "HALTING" führen haben wir in der Tat nichts gewonnen... :(

asgard

es scheint nicht zu funktionieren...ich versuchs aber später nochmal...muss jetzt mal wieder was lernen...

robert_s

#47
20. Jan 2008, 12:59 Last Edit: 20. Jan 2008, 13:01 by robert_s

1. Im Hash von nk.bin ab Offset 0x21C eine Ziffer zu verändern (z.B. gleich aus der ersten "9" eine "8")


Hmm, das ist gar nicht so gut fällt mir gerade ein. Bitte diesen Punkt ersetzen durch:

1. Den Dateinamen "bootprf.bak" ab Offset 0x262 zu verändern, z.B. das erste "b" in ein "B" verwandeln (also 0x262: 0x62 -> 0x42)

Wenn der Hash geprüft wird, ist das kein Problem, den kann man ja bei einem veränderten NK.BIN einfach neu berechnen lassen. Wichtig ist nur, ob die Signatur (die lange Hexzahlenfolge davor) geprüft wird, denn die wird ungültig, sobald man irgendetwas in der SIG-Datei (von Offset 8 bis inkl. Offset 0x2A3) verändert...

robert_s


jetzt hängt er bei mir an dieser stelle.
er will cgbf01001.iptv.t-online.de/bootstrap/Bootstrap.asmx aufrufen..diese datei gibt es bei mir aber nicht (auf dem webserver).
Ausserdem weiss ich nicht, was hier erwartet wird bzw. was der rückgabewert sein soll.

Kann mir da jemand weiterhelfen?


Das ist nicht mehr so spassig: Der sendet verschlüsselte und digital signierte Nachrichten und erwartet ebensolche. Es wird höchstwahrscheinlich ein SOAP "LoginEx" Request sein. Kannst Du übrigens auch durch decompilieren von TV2DRACE.exe herausfinden. Ich habe auch mal eine "Dummy" tv2engine.dll gebastelt, und mit der läuft dann TV2DRACE.exe tatsächlich auf einem Windows XP PC mit .NET Framework 2.0 - TV2DRACE.exe ist nämlich ein CPU-unabhängiges CLI-Binary...

robert_s


Ich habe einen DNS Server aufgesetzt (gleiche Adresse wie TFTP). 2 Hosts müssen bekannt sein (discovery.iptv.t-online.de und cgbf01001.iptv.t-online.de). Für den zweiten Host habe ich einen Alias zum ersten gebaut.
Ergebnis:
nach ca. 10 sekunden zeigt die Box "T-Home" (über Video die zwei Zahnräder), soll heißen, daß alles über TFTP erfolgreich geladen wurde.


Probier' doch bitte auch mal, eine wie hier beschriebene:

http://www.t-hack.com/forum/index.php?topic=64.msg566#msg566

modifizierte DRA-Datei der Box unterzuschieben. Wenn man das irgendwie hinbekäme, ginge das nach Deiner Methode ja sogar ganz ohne die Box aufzuschrauben...  8)

Uwe_P

Das Ändern in OEM frißt er, das große B nicht.
Wäre ja auch zu einfach...

Gruß Uwe

Hoernchen

#51
20. Jan 2008, 17:03 Last Edit: 20. Jan 2008, 19:13 by Hoernchen
Nach etwas iptables-gebastel zwecks anpassung der ip hab ich das selbe Spielchen mal mit meinem X301T gemacht, leider mit dem selben Ergebnis: dra geht, Modifikationen gehen nicht, nk.bin von der hdd geht auch nicht.

Für die anderen X301T-geschädigten :

Linuxkiste mit iptables, box hängt an eth0 und hat die ip 192.168.2.127 (am besten anhand der mac per dhcp statisch zuweisen), eth0 hat die ip 192.168.2.1

iptables -t nat -I PREROUTING -i eth0 -d 0.0.0.0 -j DNAT --to-destination  192.168.2.1
iptables -t nat -I POSTROUTING -o eth0 -d  192.168.2.127 -j SNAT --to-source 0.0.0.0

Ansonsten braucht die Kiste natürlich noch einen dhcpserver und einen tftpserver die beide auf eth0 lauschen.
Als Linuxkiste kommt eigentlich sogut wie jeder Router (egal ob OpenWrt oder nur irgend eine Fritzbox) in frage, sofern man denn irgendwie per ssh oder telnet darauf zugreifen kann.
bringer of linux, conqueror of hdmi, jack of all trades.

Hoernchen

Nochmal zu der sache mit der "1" an der richtigen Adresse um den Signaturcheck zu überspringen : welche Adresse wäre das denn bei Version 1053 des bootloaders ?
bringer of linux, conqueror of hdmi, jack of all trades.

robert_s

Die Adresse ist dieselbe in allen bekannten Bootloader-Versionen (1039, 1051 und 1053): 0x937E1728.

Hoernchen

Um meine Verwirrung einzugrenzen : gilt das für das Booten der dra-Datei bei gebrücktem JP2, oder nur für die normale nk.bin auf der Platte ?
bringer of linux, conqueror of hdmi, jack of all trades.

Hoernchen

Hab jetzt mal etwas gespielt, die idee war, einfach einen neuen Record in die nk.bin einzufügen, der dann 0x00000001 an die Adresse 0x937E1728 geladen wird.
Das Format der nk.bin ist eigentlich im grossen und ganzen "recht einfach", relevant sind eigentlich nur am Beginn 7 bytes "sync", image start 0x91e00000 und dann UInt32 länge, die sich einfach durch zusammenzählen der länge aller records ermitteln lässt - in diesem fall einfach +0x04. Ansonsten muss noch das Dateiende modifiziert werden, einfach vor das 000000000400E09100000000 ganz am Dateiende einen neuen Record einfügen, 28177E93040000000100000001000000 - lade-Adresse 0x937E1728, record-Länge 0x00000004, Checksum-32 0x00000001 und natürlich noch die "Daten", 0x00000001. Klappt aber leider nicht so wie ich mir das vorgestellt habe, denn die box will die nk.bin dann nicht mehr booten :(
Allerdings bin ich müde, da überseh ich gerne offensichtliche Fehler...
bringer of linux, conqueror of hdmi, jack of all trades.

mce2222

diese Idee hatte ich ja auch schon in einem vorherigen post geschrieben... allerdings hatte ich mir den Ladevorgang noch mal
angesehen als ich nach einem besseren Patch gesucht hab.

Dabei ist mir dann aufgefallen, dass das NK.BIN zwei mal geladen wird... erst wird nur der Hash ermittelt... dann wird dieser gecheckt gegen den Wert aus der boot.sig
und erst danach wird die NK.BIN direkt in den Speicher geladen wo sie hingehört.

... dumme Sache das die Jungs in Redmond mal was richtig gemacht haben (aus der Security-Sicht)

robert_s

Was ist eigentlich mit dem Code, der den Bootloader aus dem Flash liest und entschlüsselt ins RAM schreibt, kommt man an den irgendwie ran oder ist der im SMP8634 versteckt? Vielleicht prüft der ja ein "debug bootloader" flag im Flash-ROM und setzt 0x937E1728, wenn das der Fall ist...? Weil ich die Codestelle vermisse, wo 0x937E1728 gesetzt wird. Kann natürlich auch sein, dass das ganz clever mit einem "krummen" Offset gemacht wird, a la 0x937E1720 in $v0 vorladen und dann 8($v0) setzen. Da gäbe es ja beliebig viele Kombinationen, sodass der Code nicht allzu leicht aufzufinden wäre...

mce2222

das Entschlüsseln des Roms macht das XOS... da kommt man nicht ran.
wo das Flag gesetzt wird ist mir auch nicht ganz klar. vermutlich ist der Speicherbereich auch im verschlüsselten rom enthalten und wird einfach nur kopiert.

Hoernchen


Dabei ist mir dann aufgefallen, dass das NK.BIN zwei mal geladen wird... erst wird nur der Hash ermittelt... dann wird dieser gecheckt gegen den Wert aus der boot.sig

Grmphf.Genau das hatte ich befüchtet, wäre ja auch zu schön gewesen wenns so einfach wäre :(
Ich ging davon aus das der Bootloader nicht einfach mal so auf die HD zugreifen kann um die boot.sig zu lesen, und daher wince das nach dem Start macht.
Der Gedanke macht jetzt am hellichten Tag natürlich garkeinen Sinn mehr, wozu den Bootloader patchen, wenn sich wince selber prüfen würde, autsch...
bringer of linux, conqueror of hdmi, jack of all trades.

Go Up