ucodes & co

[Hoernchen]

XTLBoot.bin und XTUApp_1.2_XosE0.bin sind xtasks, XTUBoot.bin und XTUApp_1.2_XosE0.bin sind die dazugehörigen xunload-Dateien. Man kann sie unter Linux mittels xrpc -xload laden, per xrpc -xstart unter Angabe des Slots in den sie geladen wurden starten, per xrpc -xkill killen und per xrpc -xunload wieder entladen - wozu der kram gut ist weiss ich aber auch nicht
In der booter.dll verstecken sich zwei Dateien im xload-Format, die Erste ist wohl der irqhandler, wozu die andere gut ist hab ich noch nicht herausgefunden, sie hat aber exakt die selbe Grösse wie die erste Datei.
Und dann wäre da noch die checkxos.exe, in der einemal ein xosPe0 drin steckt, und dann noch eine zweite xload-Datei, die auch die selbe Grösse hat wie die erste - vielleicht das im xtask erwähnte xosE0 ?

Wirklich seltsam ist das sich ansonsten nirgends irgendwelche xload-Dateien finden lassen - wo zum Henker bekommt das Windows CE seine ucodes her ?!

[badsurfer]

If we cut out the first 76 bytes and mount it, we get:

-rw-r--r-- 1 root root  881252 Jan  1  1970 10xrpc_xload_audio_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rw-r--r-- 1 root root  326500 Jan  1  1970 11xrpc_xload_video_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rw-r--r-- 1 root root   30724 Jan  1  1970 12xrpc_xload_demux_ucode_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rwxr-xr-x 1 root root     773 Jan  1  1970 30vsyncparam_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.zbf
-rwxr-xr-x 1 root root   34262 Jan  1  1970 31bitmap_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.zbf
-rw-r--r-- 1 root root    6404 Jan  1  1970 32xrpc_xload_dviinit_prod.bin
-rw-r--r-- 1 root root  189524 Jan  1  1970 33xrpc_xload_irq_handler_SMP8634_2.7.176sybs1.7972x_GCC4_facsprod.bin
-rw-r--r-- 1 root root 3975492 Jan  1  1970 50xrpc_xload_vmlinux_ES4_prod.bin
-rwxr-xr-x 1 root root      64 Jan  1  1970 dvi.bin

Definitely hardware boot. Loads the various microcodes for the Sigma 8635 chip, which personally I am not interested in. Lastly we appear to have the kernel itself at about 4Megs. However, all up, the whole thing is only 5MB in size. So there is more in the first file after the romfs. One of the values in the header is probably an offset. The size of the romfs is roughly 5.2MB, or 00531c00 in hex. Romfs header has 005318f0, plus 76 bytes at a guess.

http://www.lundman.net/wiki/index.php/NMT:firmware

Kennt ihr bestimmt schon, dachte es könnte helfen...

[mce2222]

ja das sind die standard Linux uCodes... WENN die laufen würden dann wär alles super und wir könnten auf Linux umsteigen.

leider lassen sich die uCodes aber auf keiner MS IPTV box laden, und so wie es aussieht wird sich das auch nicht ändern.

[pcgeil]

jedoch kann die "Sperre" doch nur ein Softwareproblem sein.

Die werden doch nicht extra für IPTV Boxen eigene Chips produzieren.
Der Bootloader auf dem externen Flash ist wohl das Übel und gleichzeitig die Lösung.

Bin ich richtig informiert, dass als Hash Verfahren der SHA1 eingesetzt wird? Wenn ja mit welcher Länge?

[mce2222]

eigene chips nicht, wenn du dich auf die reinen physikalischen parameter beziehst.
die CPUs haben allerdings internen Speicher der diverse Zertifikate für verschiedene Anwendungen enthält.
eins für den bootloader, eins für user applications, mehrere für die verschiedenen uCodes.

all diese Zertifikate lassen sich theoretisch per Software updaten, aber diese "certificate-binding-tokens" sind natürlich auch signiert durch ein Sigma Zertificate was im Boot-ROM der CPU festverdrahtet ist.

also ich behaupte mal, das ist extrem sicher.

der hashes sind soweit ich weiss überall SHA1 (160bit) aber das ist auch kein wirklicher Ansatzpunkt, denn beim Dateicheck wird auch die Dateigrösse gecheckt also sind Kollisionen extremst unwahrscheinlich. bei den Zertifikaten ist zusätzlich noch ein MD5 hash dabei und 2 übereinstimmende Kollisionen bei MD5+SHA1 zu finden ist auch eher aussichtslos.

[pcgeil]

ok, also diese informationen habe ich bislang noch nicht gehabt.

Müsste ein Hersteller nicht dieses Sigma Zertificate haben, sobald er Boxen herstellen lässt? :-)

das mit den kollisionen hört sich auch nicht wirklich positiv an



Mensch, so ne schöne Box, aber solch ein Sicherheitsstandart, das tut echt weh.

[robert_s]

Mensch, so ne schöne Box, aber solch ein Sicherheitsstandart, das tut echt weh.

Ist ja auch im Sinne der Telekom, wenn ihre teuren subventionierten Boxen nicht zu hochwertigen Universal-Mediaplayern zweckentfremdet werden. Die Dinger sollen als VoD-Boxen umsatzbringend für die Telekom eingesetzt werden und sonst nichts.

Für einen zu diesem Zweck entworfenen SMP863x Universal-Mediaplayer muss man schon mehrere hundert Euro hinblättern...

[yoshi2001]

eigene chips nicht, wenn du dich auf die reinen physikalischen parameter beziehst.
die CPUs haben allerdings internen Speicher der diverse Zertifikate für verschiedene Anwendungen enthält.
eins für den bootloader, eins für user applications, mehrere für die verschiedenen uCodes.

all diese Zertifikate lassen sich theoretisch per Software updaten, aber diese "certificate-binding-tokens" sind natürlich auch signiert durch ein Sigma Zertificate was im Boot-ROM der CPU festverdrahtet ist.

In wie weit ist mittlerweile das Pin out der SMP CPU bekannt ?
Es kann sein das man eventuell an der Außenbeschaltung der SMP CPU was drehen kann.

Kann man nicht dahingehend mit andere Receiver vergleichen die, die selbe CPU haben ?

[Hoernchen]

Das Pinout is bekannt, da lässt sich nichts mit anfangen.

[yoshi2001]

Wie gut ist eigentlich das Boot ROM in der CPU gesichert ?

Ich denke da an Glitch oder Dump Attacken so wie man das von Pay TV Smartkarten her kennt.
Währe sowas überhaupt in dieser Richtung möglich ?

[Hoernchen]

Die Frage ist nicht ob irgendwer mit seiner FIB-Workstation und SEM in der Küche das Ding zerlegen kann sondern ob ich das auch ohne all die Speziellen Geräte schaffe die ich gern hätte aber nicht habe. Der erste Bootloader ist fest verdrahtete Hardware in der XPU die das XOS lädt welches verschlüsselt im Serial Flash der XPU vorliegt, die Keys dazu liegen selber verschlüsselt im serial Flash, und das wiederum lädt dann den verschlüsselten ITPV-Bootloader aus dem externen Flashchip und veranlasst die Host CPU diesen auszuführen. Ich kann also vollkommen blind im mehrstufigen Bootprozess herumglitchen, das ist dann aber so effektiv wie einfach auf ein Wunder zu warten.

[yoshi2001]

Da hat wohl Sigma gute Arbeit geleistet das System so sicher wie möglich zu machen.

Gibt es denn noch eine reelle Chance jemals was in dieser Richtung zu machen ?

Es kann doch nicht sein das dieses Projekt nur an diesen verflixten Verschlüsselten Boot Rom in der CPU scheitert.

[Hoernchen]

Zumindest momentan siehts so aus als würde Linux an den verflixten ucode-Zertifikaten scheitern, es deutet alles darauf hin das das wince keine normalen ucodes benutzt bzw das irgendwie anders löst. Das Problem könnte natürlich auch anderswo liegen, aber es gibt leider nichtmal eine Handvoll Leute hier die die hardwarenahen sachen erforschen. Ohne ein besseres Verständnis wie das wince arbeitet kann man auch da wenig sinnvolles Basteln, von fast schon trvialen Configänderungen des tv2client mal abgesehn.

[pcgeil]

Also ich habe ein bisschen im Internet gestöbert und folgendes gefunden.

http://blog.chinaunix.net/u2/62451/showart_1193078.html

Hat jemand den:
smp86xx_boot_loader_2.8.0.1
bzw.
CPU_KEYS_SMP8634_xosMc0-1.tar.gz

Die Datei mrua_SMP8634_2.8.0.1_dev.mips.tar.gz findet man ja relativ einfach. :-)

Und in der Readme steht:
This README covers the usage of xpu utilities included in the mRUA package.

This README does NOT cover certificate requests and generation of
binding tokens:
See the CPU_KEYS package.
This README does NOT cover development of xtasks:
See the XSDK package.
This README does NOT cover the process of building a secure bootloader:
See the mipsutils packages.

Also wäre sehr interessant, wenn man diese Pakete hätte.

[pcgeil]

In dem Bootloader, welcher man dumpen kann sieht man ja, dass es verschiedene Texte zum Microcode gibt.
Zum einen, eine Meldung, dass die Micocodes schon geladen wurden, zum anderen, gibt es Meldungen während dem Laden von Microcodes.

Besteht die Möglichkeit, dass schon der IPTV Bootloader die Microcodes lädt?
Oder sind die vorhandenen Strings unrelevant?

Wenn die Microcodes schon während dem IPTV Bootloader geladen würden, wäre es auch nachvollziehbar, wieso WinCE nur noch die xtasks lädt.