Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - t-homme

1
Nein, mit der Vista bzw. XP- MCE hat der Tasman nichts gemein.

Die MCE verwendet einen speziellen XML-Dialekt, der natürlich auch Ähnlichkeiten zu XHTML besitzt, aber da hörts schon auf.
Die MCE ist wesentlich moderner und nicht so ein Monolith wie der Tasman, der ja nur eine Verlegenheitslösung ist, weil MS wohl keine andre Codebasis für Browser hat, die nicht auf Intel-x86- Prozessoren laufen.

Die Tendenzen bei MS gehen aber ohnehin wie üblich weg von Standards wie XHTML zu eigenen Markup-Languages wie XAML (bei Vista WPF und Silverlight) und es täte mich nicht wundern, wenn da in dieser Richtung weiterentwickelt und der Tasman nur Hinhaltetaktik ist.

Per RDP einen PC mit dem IE fürs Kundencenter und die Hilfeseiten zu benutzen, kann jedenfalls sicher nicht die Lösung für die geplanten Ausbreitungsstückzahlen der T-Home Boxen sein- es sei denn, man will MS noch reicher mit den ganzen Windows-Lizenzen machen, die man für sowas braucht.  ;D

2
Das Developer Kit der Telekom entspricht wohl höchstens der MS Mediaroom ADK (Application Developer Kit, früher IPTV CDK).

Es besteht aus einem Simulator des Tasman-Browsers, der übrigens nix mit dem Windowa-IE zu tun hat, sondern auf der Code-Basis des IE-5 für den MAC aufbaut- einer Totgeburt.

Im Gegensatz zum IE ist das ein standardkonformer XHTML 1.0 Browser mit Javascript und <object>-Tag Erweiterung zur Anzeige von Videos in Form von Live Channels oder MP3, WMA und WMV Dateien oder Streams. Ansonsten keine Plugins, ActiveX, Flash etc. pp.. - halt gar nix, was einen modernen Webbrowser ausmacht ausser XHTML und CSS.

Wie man auch schon im Filesystem der NK.BIN erkennt, ist der Tasman-Browser ein ziemlicher Fremdkörper in dem System, das ansonsten stark auf dem .NET Compact Framework 2.0 basiert und mit GDI+ basierenden Grafiktreibern rendert. Deshalb gibt es auch Darstellungsprobleme insbesondere bei HDTV- Bildschirmen- der Tasman kann nur  in der Auflösung 640x480 Pixeln rendern und hat auch ein eingeschränktes Farbmodell, wie die klassische Windows GDI unterstützt er etwa keinen Alpha-Kanal, kann also keine Transparenz und gescheite Fontglättung. Schlußendlich sieht alles recht scheußlich aus, was über die Box vom Tasman-Browser kommt und es stellt sich die Frage, ob es Sinn macht, sich mit derlei Anwendungen ernsthaft zu beschäftigen.

Das ist umso fragwürdiger, weil unter dem Codenamen "Milwaukee" da was wesentlich moderneres rumgeistert, obschon in den Sternen steht, wann es verfügbar sein wird.

Jedenfalls kriegt man auch mit dem Developer Kit nix auf die Box, sondern nur auf dem heimischen PC im Simulator zu sehen. Erst die Telekom kann über ein ServiceTool URLs, die solche XHTML-Seiten hosten, über Channelnummer erreichbar machen und erst dann stellt sich raus, ob diese "Anwendungen" wirklich über einen Fernseher gut funktionieren, weil im Simulator alles viel schicker aussieht als später auf der Box und nicht z.B. Farbkombinationen gewählt wurden, die auf dem Fernseher heftig flimmern oder Bereiche auf dem Fernseher gar nicht mehr zu sehen sind.

Besser ist es also zu warten, bis entweder Microsoft oder die Telekom ein Einsehen haben und vernünftige Entwicklungswerkzeuge bereitstellen oder in dieser Community lange genug weiterzumachen, bis das nicht mehr nötig ist.
3
@Paul

Ok, das Knacken einer Verschlüsselung an sich ist natürlich nicht strafbar.
Wohl aber ein Verstoß gegen die Novelle des Urheberrechts, erster Korb:


[font=haettenschweiler]Es bleibt auch bei dem Verbot, einen Kopierschutz zu knacken. Das ist durch EU-Recht zwingend vorgegeben. Die zulässige Privatkopie findet dort ihre Grenze, wo Kopierschutzmaßnahmen eingesetzt werden. Die Rechtsinhaber können ihr geistiges Eigentum durch derartige technische Maßnahmen selbst schützen. Diesen Selbstschutz darf der Gesetzgeber ihnen nicht aus der Hand nehmen. Es gibt kein „Recht auf Privatkopie" zu Lasten des Rechtsinhabers. Dies ließe sich auch nicht aus den Grundrechten herleiten: Eine Privatkopie schafft keinen Zugang zu neuen Informationen, sondern verdoppelt lediglich die bereits bekannten.
[/font]

Wenn der Rechteinhaber also nicht will, das Kopien (Videorecorder) aufgezeichnet werden, verstößt man gegen das Urheberrecht, wenn man die Maßnahmen, die das verhindern sollen -also üblicherweise Kryptographie- aushebelt.
4

@Dominator: mce2222's Beitrag war wohl eher ironisch gemeint.

Gerade beim X301T wird man die von außen auch per Hardware nicht zugängliche OnChip- Kryptographie wohl kaum "hacken" können. Der Versuch, die Ballgrid-Anschlüsse des Prozessors mit feinem Bohrer und Rumlöten zu treffen, um da mit Fädeldraht ein JTAG- Interface zum Anschluss eines InCircuit Debuggers, der auf einem PC läuft, wird wohl zu 99.5% mit dem Ableben der Box gestraft.

Hat man das dann doch irgendwie geschafft, muß man erst mal den Bootstrapper disassemblieren und mit dem InCircuit Debugger an den richtigen Speicherstellen patchen.
Dann braucht man noch gepatchte Versionen vom Betriebssystem-Rom-Image und schlußendlich eine gepatchte TV2- Client-Anwendung, um festzustellen, daß derlei Rechteverwaltung sowieso auf dem Server passiert, an den man eh nicht rankommt und eine Kommunikation mit den entsprechenden Webservices kann man ohne Knacken von seit Jahren  als unknackbar bewährten, zertifikatsbasierten Kryptographieverfahren auch nicht bewerkstelligen.

Achso- und strafbar ist das Knacken von Kryptographie natürlich sowieso.
5
Software / Re: Format der DRA Datei
24. Jan 2008, 15:35

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.
6
Software / Re: Format der DRA Datei
24. Jan 2008, 09:47

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.
7
Software / Format der DRA Datei
23. Jan 2008, 12:52

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?