Vielleicht schaffen wir das über tftp anstelle eines jtag-patches....das wäre doch eine super alternative falls das gehen würde...
Ich verweis nochmal auf den ansatz von robert_s:
http://www.t-hack.com/forum/index.php?topic=49.msg492#msg492 (http://www.t-hack.com/forum/index.php?topic=49.msg492#msg492)
Vielleicht schaffen wir das über tftp anstelle eines jtag-patches....das wäre doch eine super alternative falls das gehen würde...
Die entsprechenden Codestellen sind übrigens identisch in den BL-Versionen 1039 und 1051, nur in der 1053 sieht das anders aus. Also könntest Du auch mit Deinem Receiver mal probieren, was passiert wenn Du JP2 brückst. Zumindest erscheint es mir möglich, dass man damit einen unsignierten NK.BIN einschleusen könnte. Und da dort wiederum BooterCE.exe drinsteckt, könnte man auch dessen Signaturcheck abschalten. Die Schwierigkeit wäre dann nur noch, dass Nachladen weiterer Dateien zu ermöglichen, damit man sich den Ausbau der Festplatte ersparen kann.
Wenn man das gebacken bekäme, würde die Überbrückung von JP2 ausreichen, um 1039er und 1051er Boxen "freizuschalten", ganz ohne JTAG oder Ausbau der Festplatte...
der Datei transfer ist doch auch geregelt... in meinem BooterCE ist ein FTP server enthalten.
von daher wärs schon nicht schlecht wenn das mit dem netboot klappt.
hat sich eigentlich jemand den DHCP request genauer angesehen ?
wenn ich mich recht entsinne, gibt es in WinCE eine Kernel Netboot option, über die man mit VisualStudio neue Kernels bereitstellen kann.
Das läuft dann auch mit TFTP
wenn ich mich recht entsinne, gibt es in WinCE eine Kernel Netboot option, über die man mit VisualStudio neue Kernels bereitstellen kann.
Das läuft dann auch mit TFTP
Geht's nicht gerade genau darum? Jedenfalls spuckt der Bootloader "NETBOOTING" aus, wenn er NK.BIN per TFTP von 192.168.1.200 laden möchte/sollte. Der entsprechende Code fängt im Bootloader 1051 übrigens an Adresse 0x9363FD74 an. Da wird 2x IPTV_HAL_FrontPanel_VFD_DisplayState() aufgerufen, danach IPTV_HAL_Global_GetNetBootParams() und dann will er NK.BIN an Speicheradresse 0x90A00000 mit maximal 0x1200000 Bytes Länge laden. Wenn das klappt, springt er über eine Zwischenadresse an genau die Adresse, an die auch Dein gepatchter Bootloader springt...
also,
was muss sich genau machen?
- IP von einem Rechner auf 192.168.1.200 einstellen
- TFTP-Server auf diesem Rechner installieren und konfigurieren (gepatchte NK.bin bereitstellen)
- JP2 überbrücken
- Wireshark starten, um zu schauen, was der X300T dann so macht...
- X300T einschalten und abwarten...
hab ich was vergessen? dann leg ich gleich mal los...
edit...wurden vervollständigt...danke an robert
Da fehlen noch die Schritte (an den passenden Stellen einzufügen):
- JP2 überbrücken ;)
- Wireshark starten, um zu schauen, was der X300T dann so macht...
und ggf.:
- Wireshark-Capture an robert_s mailen, falls es irgendwo haken sollte
Hey robert,
du warst einfach zu schnell...ich musste grd nur dringend aufs klo....da ist mir dann aufgefallen, dass ich den jumper 2 vergessen hatte...
naja...was solls :)
Danke für den hinweis :P
Noch ein Punkt: Der DHCP-Server (also z.B. Dein Router) sollte sich ebenfalls im 192.168.1.x Subnetz befinden, damit der X300T die 192.168.1.200 nicht über den Gateway/Router zu erreichen versucht...
Aber erstmal schauen, ob der X300T mit gebrücktem JP2 überhaupt einen DHCP-Request macht... Und dann noch einen ARP-Request, um die MAC-Adresse zur 192.168.1.200 zu finden.
Gibts in wireshark noch irgendwas spezielles was ich einstellen sollte?
oder einfach loslegen?
Gibts in wireshark noch irgendwas spezielles was ich einstellen sollte?
oder einfach loslegen?
Default-Einstellungen sollten reichen. Einfach auf den ganz linken Toolbar-Knopf mit der stilisierten Netzwerkkarte klicken, richtige Netzwerkkarte im "Capture Interfaces" Fenster finden und rechts daneben auf "Start" klicken. Dann den X300T starten.
Der Übersichtlichkeit halber solltest Du dabei keine Downloads machen ;) Und auch nicht im Web surfen...
also,
bisher hab ich nicht viel hinbekommen....wenn ich den j2 schließe bekomme ich am seriell ausgang neben den üblichen infos noch ein "netbooting".
Wenn ich nun lange warte, erscheint zusätzlich ein "halting" und das display blink mit der meldung "keine Verbindung".
Im Router meldet sich die Box mit dem Namen "RM4100" an.
So ähnlich wie bei meinem X301T sollte es auch beim X300T aussehen.. ich war mal so frei meinen dump anzuhängen.
Nach dem letzten Packet erscheint dann "Keine Verbindung" auf dem Display.
edit : anhang wieder entfernt, bevor die telekom noch auf die idee kommt meine kiste zu sperren...
So ähnlich wie bei meinem X301T sollte es auch beim X300T aussehen.. ich war mal so frei meinen dump anzuhängen.
Nach dem letzten Packet erscheint dann "Keine Verbindung" auf dem Display.
Interessant, er schickt die Requests an die MAC-Adresse des DHCP-Servers... Im DHCP-Datenverkehr sehe ich, dass die Felder "Client IP Address" sowie "Relay agent IP Adress" jeweils auf 0.0.0.0 stehen - ob der X301T eins dieser beiden Felder für die Adresse des TFTP-Servers nimmt?
Wireshark zeigt mir auch was an...aber nichts sinnvolles (??)....
Nicht mal ein DHCP-Request? Ja, die TFTP-Requests gehen an Port 69, zumindest in @Hoernchens Capture...
huhu,
es gibt was neues....es scheint ein wenig zu funktionieren...
Leider gibts am ende einen fehler und er macht nicht weiter...also nachdem die nk.bin komplett per tftp gezogen wurde...liegt evtl. an meiner nk.bin...kann mir einer eine zukommen lassen...zwecks abgleich?
asgard(ÄÄÄTTT)t-hack.com
Danke!
Grml. Da haben die Telekomiker wohl nicht nur die JTAG-enable-leitung bei der X301T "vergessen", sondern auch die Ipaddresse des TFTPServers, meiner Netzwerkkarte 0.0.0.0 aufzuzwingen wird wohl schwierig werden...
Grml. Da haben die Telekomiker wohl nicht nur die JTAG-enable-leitung bei der X301T "vergessen", sondern auch die Ipaddresse des TFTPServers, meiner Netzwerkkarte 0.0.0.0 aufzuzwingen wird wohl schwierig werden...
Wenn Du ein bisserl proggen kannst, könntest Du probieren, mit dem WinPCap Developer Kit ein Tool zu basteln, welches direkt unter Umgehung des TCP/IP-Stacks einen TFTP-Server für die Adresse 0.0.0.0 implementiert...
Leider gibts am ende einen fehler und er macht nicht weiter...also nachdem die nk.bin komplett per tftp gezogen wurde...
Auch kein Datenverkehr auf dem Netzwerk mehr?
Hmm, könntest Du mal probieren, während des TFTP-Downloads den JTAG Bootloader-Patcher auszuführen? Eventuell liegt da ja doch noch ein Signaturcheck im Weg...
Mein erster Gedanke war bereits atftpd zu hacken, mein zweiter war per iptables src und dest "anzupassen", und mein dritter das ich dringend für meine Klausuren lernen sollte statt mich angenehmer interessanter Bastelarbeit zu widmen :-\
..., und mein dritter das ich dringend für meine Klausuren lernen sollte statt mich angenehmer interessanter Bastelarbeit zu widmen :-\
same here!
Leider gibts am ende einen fehler und er macht nicht weiter...also nachdem die nk.bin komplett per tftp gezogen wurde...
Auch kein Datenverkehr auf dem Netzwerk mehr?
Hmm, könntest Du mal probieren, während des TFTP-Downloads den JTAG Bootloader-Patcher auszuführen? Eventuell liegt da ja doch noch ein Signaturcheck im Weg...
nein, kein datenverkehr mehr auf dem netzwerk...
Ich habe gerade die orignale (ungepatchte) Nk.bin draufgeladen....selbes problem....es erscheint die meldung "Fehler".
Jtag kann ich nicht nutzen, weil es räumlich nicht möglich ist...sorry (kein notebook mit lpt vorhanden :( )
Vielleicht kann einer mal weiter reverse engineeren...was man noch braucht bzw. was nach dem upload per tftp passieren müsste...ich persönlich hab davon keine ahnung
Leider gibts am ende einen fehler und er macht nicht weiter...
so wie das ausschaut geht deine festplatte nicht
erkennt man auch an dem fehlenden roten kreis dingens
hatte ich auch mal als ich versehentlich das ide kabel etwas schief angeschlossen hatte.
daran liegts nicht....mit offenem J2 gehts...
Ich habe gerade die orignale (ungepatchte) Nk.bin draufgeladen....selbes problem....es erscheint die meldung "Fehler".
Welche NK.BIN hast Du genommen? Die aus der Software 1.2.2099.2, oder die aus der Datei "dra"? Könnte sein, dass letztere an dieser Stelle "passen" würde...
Ich habe gerade die orignale (ungepatchte) Nk.bin draufgeladen....selbes problem....es erscheint die meldung "Fehler".
Welche NK.BIN hast Du genommen? Die aus der Software 1.2.2099.2, oder die aus der Datei "dra"? Könnte sein, dass letztere an dieser Stelle "passen" würde...
Ich habe die version von der festplatte genutzt...welche das jetzt ist, weiß ich leider nicht...ich nehme mal an, dass es die letzte version ist, die veröffentlicht wurde.
wenn mir jemand sagt, woher ich das dra-file bekomme...und wie ich daraus eine nk.bin bastel, dann versuch ichs mit der version, sofern die unterschiedlich sind!
Ich habe die version von der festplatte genutzt...welche das jetzt ist, weiß ich leider nicht...ich nehme mal an, dass es die letzte version ist, die veröffentlicht wurde.
Das ist die aus der Software 1.2.2099.2. Ich maile Dir gleich mal die aus "dra" extrahierte NK.BIN...
ok, danke!
was mir da grade noch so kommt...was für nk.bin versionen gibt es denn noch?
Ich denke da an andere Boxen mit dem selben chip...vllt funzt davon eine version...
Das ist die aus der Software 1.2.2099.2. Ich maile Dir gleich mal die aus "dra" extrahierte NK.BIN...
selbes Problem...es erscheint "fehler" auf dem Display und ein rotes Kreuz bzw. X auf dem Fernseher
Ebenso mit der Dune-NK.bin...und der popcorn-nk.bin
selbes Problem...es erscheint "fehler" auf dem Display und ein rotes Kreuz bzw. X auf dem Fernseher
Und am seriellen Port? Kommt da immer noch "HALTING" raus?
Hi,
I'm (think I am) following this thread with interest and note that there seems to be trouble with getting tftp to accept nk.bin..
I was looking for further information and found the following in an MSDN article regarding how to load a wince5 image without using platformbuilder:
* The TFTP server is waiting for a file named "boot.bin" (defined as EDBG_DOWNLOAD_FILENAME), it won't accept any other file names. So, you will have to rename the file that platform builder creates (NK.bin) to "boot.bin."
The link for the entire article is : msdn2.microsoft.com/en-us/library/aa446908.aspx
Thought this might be relevent to this discussion.. if my rusty german doesn't deceive me..
Redband...
Hey Redband,
we can upload a NK.bin to the box. But unfortunately the box reject it and says "Fehler".
We also tried an unpatched/unmodified version...but we have the same problem.
selbes Problem...es erscheint "fehler" auf dem Display und ein rotes Kreuz bzw. X auf dem Fernseher
Und am seriellen Port? Kommt da immer noch "HALTING" raus?
hab grad kein seriell mehr angeschlossen...sorry :(
Did you try a renamed version? eg called boot.bin?
@redband I am quite sure that you are right. Haven't tried the netbooting yet, but I see in the bootloader code, that there is a string "boot.bin" and I also see that the TFTP server is initialised with handling methods, based on the transfered filename.
when there is no handler for the filename, it will just fail to process the transmitted data.
EDIT:
ok. now I realise that there are two netbooting methods in the bootloader. one is the standard WinCE edbg boot, which redband also refers to.
but the second is something that is totally different, since it actively downloads a NK.BIN from a fixed IP address.
I have no idea how to enable the standard WinCE netbooting code.
anyway... this active NK.BIN download also goes thru the signature check... so there is nothing gained.
Wo siehst Du das denn bitte? Ich sehe in den Packetdumps jedenfalls nur, dass der Receiver per TFTP die Datei "NK.BIN" anfordert. Und da der TFTP-Server soweit ich das sehe keinen Dateinamen übermitteln kann, gibt es da keine Möglichkeit, irgendetwas unter dem Namen "boot.bin" zu übertragen...
Übrigens wird dieser "NETBOOT" mit den GPIO-Pins 19, 30 und 31 ausgelöst:
GPIO-Pins 30 und 19 ergeben die "Board ID", GPIO-Pin 31 triggert dann abhängig von dieser den NETBOOT:
30=1/19=0 -> ungültig (kein NETBOOT möglich)
30=1/19=1 -> Board ID = 1 (kein NetBOOT möglich)
30=0/19=0 -> Board ID = 2, NETBOOT wenn 31=1
30=0/19=1 -> Board ID = 3, NETBOOT wenn 31=0
Die "Board ID" wird an einigen Stellen im Bootloader benutzt, aber was sie genau bedeutet ist mir nicht ganz klar. Auch weiss ich nicht, welchen GPIO-Pin der JP2 eigentlich verändert...
this active NK.BIN download also goes thru the signature check... so there is nothing gained.
Der scheint mir aber nur noch durch den zweiten Check zu gehen, welcher sich durch eine 1 an der Adresse 0x937E1728 deaktivieren lässt. Also zumindest hätte man dadurch:
1) Einen vereinfachten Patch
2) Einen besseren Patchzeitpunkt (während des NK.BIN-Downloads)
gewonnen. Und wenn man dann noch herausfände, ob es nicht vielleicht doch irgendeine vorgesehene Möglichkeit gibt, die Adresse 0x937E1728 auf 1 zu setzen...
P.S.: Muss [0x937E1728] eigentlich 1 oder != 1 sein, um den Signaturcheck zu überspringen...!?
P.P.S.: Am Signaturcheck kann's aber nicht liegen bei @asgard, schliesslich hat der die Original NK.BIN's probiert, da hätte die Signatur also passen müssen...
Noch ein Followup: Soweit ich den Code verstehe, wird nach erfolgreichem TFTP-Download von NK.BIN eine 1 nach 0x1C($sp) geschrieben. An 0x9363FF5C (BL 1051) wird dieser Wert überprüft und bei != 0 wird die Stelle übersprungen, die @mce2222's Bootloader-Patcher gepatcht hat - allerdings gleich zu "HALTING" :(
Hmm, da ist vorher ein Unterprogrammaufruf, auf dessen Ergebnis hin er das "HALTING" ausgibt oder nicht - und das sieht nach der Zerlegung von "dra" aus.
@asgard, könntest Du mal probieren, die komplette "dra" Datei (falls Du sie nicht hast, einfach mit "TFTP -i discovery.iptv.t-online.de GET dra" laden) in "NK.BIN" umzubenennen und diese der Box anzubieten...?
Wo siehst Du das denn bitte? Ich sehe in den Packetdumps jedenfalls nur, dass der Receiver per TFTP die Datei "NK.BIN" anfordert. Und da der TFTP-Server soweit ich das sehe keinen Dateinamen übermitteln kann, gibt es da keine Möglichkeit, irgendetwas unter dem Namen "boot.bin" zu übertragen...
worauf sich redband bezieht ist der WinCE netboot... dort schickt das device eine "bootme" Anfrage per UDP multicast raus und ein beliebiger Rechner kann dann per TFTP einen Kernel hochladen .. dabei muss der Name boot.bin sein.
wie schon gesagt... das hat mit dem aktiven download von der box selbst nichts zu tun.
Die "Board ID" wird an einigen Stellen im Bootloader benutzt, aber was sie genau bedeutet ist mir nicht ganz klar. Auch weiss ich nicht, welchen GPIO-Pin der JP2 eigentlich verändert...
der bootloader wird für alle MS IPTV boxen verwendet... daher die Unterscheidung in der Hardware.
Der scheint mir aber nur noch durch den zweiten Check zu gehen,
es gibt immer nur einen Signaturcheck. Der Zweite den du meinst ist ausschliesslich für den DesasterRecovery Fall... der lässt sich nicht abschalten, aber der wird durch meinen Patch auch nie ausgeführt.
1) Einen vereinfachten Patch
2) Einen besseren Patchzeitpunkt (während des NK.BIN-Downloads)
erscheint mir eher komplizierter... da braucht man dann noch die passenden IP + TFTP server.
an nem besseren Patch bin ich schon dran.
ob es nicht vielleicht doch irgendeine vorgesehene Möglichkeit gibt, die Adresse 0x937E1728 auf 1 zu setzen...
P.S.: Muss [0x937E1728] eigentlich 1 oder != 1 sein, um den Signaturcheck zu überspringen...!?
1 == skip signatur check
... wie der "richtige" Weg ist, die Addresse auf 1 zu setzen ist mir auch nicht klar.
theoretisch, könnte man das NK.BIN so modifizieren, dass ein zusätzliches Modul eingefügt wird was zufälligerweise genau an die SignaturCheck Addresse geladen wird und 4 bytes lang ist. Ich glaube kaum das in der Loader routine gecheckt wird ob die einzelnen Module innerhalb des vorher definierten Speicherbereichs liegen ;)
das könnte klappen, nur gibt es leider keine guten tools um soetwas in ein NK.BIN einzufügen. zumal es ja eigentlich auch ein defektes NK.BIN wäre wenn man es genau nimmt.
P.P.S.: Am Signaturcheck kann's aber nicht liegen bei @asgard, schliesslich hat der die Original NK.BIN's probiert, da hätte die Signatur also passen müssen...
da bin ich mir nicht sicher... falls die boot.sig Datei gar nicht geladen wird, weil ja netboot benutzt wird, dann ist der hashwert wahrscheinlich 00000000000000....
wäre ja Unsinn den Wert aus der boot.sig zu nehmen.
P.S.: Muss [0x937E1728] eigentlich 1 oder != 1 sein, um den Signaturcheck zu überspringen...!?
1 == skip signatur check
Verstehe ich nicht ganz:
lw $v0, 0x937E1728
bne $v0, $s7, 0x93640014$s7 ist mit 1 vorgeladen. Also wenn *0x937E1728 != 1 ist wird nach 0x93640014 gesprungen. Dort soll erst der Signaturcheck sein!? Ich dachte immer der wäre in dem Code ab 0x9363FF88... :(
Kannst Du mal kurz schreiben, welches Codesegment bzw. welche Aufrufe eigentlich den Signaturcheck durchführen (bei BL 1051)? Ich tappe irgendwie noch im Dustern... :(
@asgard, könntest Du mal probieren, die komplette "dra" Datei (falls Du sie nicht hast, einfach mit "TFTP -i discovery.iptv.t-online.de GET dra" laden) in "NK.BIN" umzubenennen und diese der Box anzubieten...?
das scheint zu funktionieren...nach dem er das file hat, kommen die 2 Zahnräder von der desaster-recovery...siehe foto...
macht auch Sinn, denn in der Datei ist eine eigene boot.sig dabei, die zum NK.BIN passt.
Haben wir evtl. noch andere Dra-files...also von anderen boxen, zum testen?
zum beispiel von btopenworld.com ?
Habe jetzt auch mal diverse Tests mit der 301er bzgl. TFTP gemacht. Hier die Ergebnisse:
Mit gesetztem JP2 (bei der 301er JP11) funktioniert TFTP nicht. Die Anfragen gehen alle an 0.0.0.0. Das wird so schlecht funktionieren. Also Plan B...
ohne JP11
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.
Jetzt versucht die Box HTTP Anfragen an den T-Home Server zu senden (versucht wahrscheinlich die Oberfläche zu laden).
Gruß Uwe
Hi,
soweit bin ich auch,...selbes vorgehen wie du (bis auf das tftp)...
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 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... :(
es scheint nicht zu funktionieren...ich versuchs aber später nochmal...muss jetzt mal wieder was lernen...
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...
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...
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)
Das Ändern in OEM frißt er, das große B nicht.
Wäre ja auch zu einfach...
Gruß Uwe
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.
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 ?
Die Adresse ist dieselbe in allen bekannten Bootloader-Versionen (1039, 1051 und 1053): 0x937E1728.
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 ?
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...
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)
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...
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.
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...
EDIT:
ok. now I realise that there are two netbooting methods in the bootloader. one is the standard WinCE edbg boot, which redband also refers to.
but the second is something that is totally different, since it actively downloads a NK.BIN from a fixed IP address.
I have no idea how to enable the standard WinCE netbooting code.
anyway... this active NK.BIN download also goes thru the signature check... so there is nothing gained.
Hat schon jemand probiert der Box mittels DHCP-Reply den TFTP-Server und die zu ladende File vorzugeben (so läuft ja netboot normalerweise)?
mce2222:
- geht der standard WinCE boot auch durch den signature check?
- wertet der BL überhaupt mehr als seine IP+Subnet aus beim DHCP-Reply?
Hat schon jemand probiert der Box mittels DHCP-Reply den TFTP-Server und die zu ladende File vorzugeben (so läuft ja netboot normalerweise)?
ich denke nicht das das schon jemand probiert hat. ich bin mir auch nicht sicher was da genau gesetzt werden muss.
- geht der standard WinCE boot auch durch den signature check?
das sollte klappen. im bootloader wird nur die NK.BIN gecheckt sonst nichts... der eboot wäre ja normalerweise nur eine alternative die NK.BIN nachzuladen. theoretisch könnte man da natürlich auch irgendwelchen anderen code reinwerfen.
aber das hauptproblem bleibt die frage wie man den eboot mode aktiviert. vielleicht hängt es tatsächlich vom DHCP reply ab.
es kann aber auch sein das der eboot code nur restmüll ist der vergessen wurde aus den sourcen zu löschen ?!?
- wertet der BL überhaupt mehr als seine IP+Subnet aus beim DHCP-Reply?
hab ich mir nie so genau angesehen.
Konfiguration:
dhcpd.conf:
host thome {
hardware ethernet 00:d0:e0:xx:xx:xx;
fixed-address 192.168.51.4;
# pxe file name on tftpd server
filename "boot.bin";
# server running tftpd:
next-server 192.168.51.1;
default-lease-time 7200;
}
Die boot.bin auf dem TFTP-Server war das yamon-Image, leider ohne Erfolg, die Box bootet normal durch und zieht sich nicht das Image oder versucht es auch garnicht erst zumindest sagt das tcpdump... :/
Leider habe ich noch nichts modifiziert an der box, daher kann ich dann auch leider nicht die Console auslesen :(
Wäre aber denk ich auch zu einfach gewesen...
Das funktioniert nicht per DHCP ... was man per Netzwerkcapture sieht ist dass der Bootloader eine Adresse aufloest die im BIOS oder im Flash eingespeichert zu sein scheint (selbst bei "leeren" Boxen) und dort per TFTP eine fest definierte Datei abholt (das scheint ein hard-codierter Pfad zu sein) und danach nochmals per TFTP connected (neuer Verbindungsaufbau) und die Datei DRANK.bin per TFTP runterlaedt.
Das funktioniert nicht per DHCP ... was man per Netzwerkcapture sieht ist dass der Bootloader eine Adresse aufloest die im BIOS oder im Flash eingespeichert zu sein scheint (selbst bei "leeren" Boxen) und dort per TFTP eine fest definierte Datei abholt (das scheint ein hard-codierter Pfad zu sein) und danach nochmals per TFTP connected (neuer Verbindungsaufbau) und die Datei DRANK.bin per TFTP runterlaedt.
JimRaynor bezieht sich auf den standard WinCE Netboot...
wie schon weiter vorne im Thread geschrieben, gibt es im IPTV Bootloader zwei netboot Möglichkeiten:
1. der standard WinCE Netboot, der selbst einen TFTP Server startet und auf eboot.bin bzw. nk.bin von einer externen quelle wartet (normalerweise Visual Studio)
2. der IPTV Netboot, der sich per TFTP eine NK.BIN von einerm externen Server abholt.
der 2. Fall bringt nichts weil die NK.BIN genauso geprüft wird, als wäre sie von der Festplatte geladen worden.
der 1. Fall wäre interessant weil zumindest das eboot.bin definitiv durch keinen signaturcheck abgedeckt ist.... es bleibt nur die Frage wie (oder OB) man diesen Modus einschalten kann. Aber selbst wenn es geht, ist es auch nicht die ultimative Lösung weil man bei jedem Start manuell die bootfiles hochladen müsste.
JimRaynor bezieht sich auf den standard WinCE Netboot...
ups sorry, ich sollte aufmerksamer lesen.
der 1. Fall wäre interessant weil zumindest das eboot.bin definitiv durch keinen signaturcheck abgedeckt ist.... es bleibt nur die Frage wie (oder OB) man diesen Modus einschalten kann.
Ich glaube bei den Sigma Referenz-Kits/SDK boards gibt es diese Option... aber dort wird meines Wissens auch nur eine NK.BIN per TFTP von der externen Quelle geladen und diese dann nach einem Signatur-Check geladen. Das bringt ja nicht wirklich einen Vorteil....
der netboot ist wenn überhaupt dann nur zum entwickeln sinnvoll.
für den Normalbetrieb ist die "modchip" Lösung immer noch die einzige Lösung... und soooo schwierig ist es ja nicht das umzusetzen ;)