ucodes & co

[pcgeil]

Vielen Dank fürs Überprüfen.

Die letzten drei Hexzahlen stimmen überein.

[pcgeil]

nochmal ne generelle Frage:

so wie ich es verstanden habe, geht man davon aus, dass die UCodes nicht laufen (von z.B. den anderen Boxen, Linux), weil diese anders signiert sind.
Ich habe mir nun mal die Mühe gemacht, die Dokumentation und das Datenblatt durchzuarbeiten und finde keine Möglichkeit, bzw. Hinweis wie so etwas realisiert sein sollte.
In Dokumentation steht über die UCodes drin, dass diese mit einem Schlüssel von Sigma nicht des Customers signiert werden.
Die xtasks werden vom DRM Provider signiert.
Oder geht man einfach davon aus, dass Sigma dieses Feature im Datenblatt weggelassen hat?


Ich habe leider keine Informationen gefunden, was genau durchgeführt wurde, als die UCodes versucht wurden zu laden.
Hat da jemand genauere Informationen darüber?

[Hoernchen]

Das gilt alles nur für das "normale" SDK, Microsoft/Alcatel haben da was völlig eigenes ohne Sigmalibs und wohl auch ohne ucodes gebastelt und sind somit der einzige Boxentwickler der eine wirkliche Dokumentation zum Chip hat und nicht blind anhand der mrua-samples herumbasteln muss. Man kann daher von ausgehn das die auch beliebige oder zumindest andere certs für die Chipteile benutzen können. Soweit die Theorie, kann natürlich sein das die windows ce BSP doch passende ucodes mitbringt, aber leider kenn ich weder eine bsp-basierte Kiste noch hab ich deren Software zur Hand um nachzuschauen :/

[mce2222]

Oder geht man einfach davon aus, dass Sigma dieses Feature im Datenblatt weggelassen hat?

ja davon gehen wir mal aus, denn dieses "feature" ist eigentlich völlig überflüssig und kann eigentlich nur als "2nd level of defense" angesehen werden,
wodurch verhindert werden soll, das die subventionierte Hardware nicht ge-hijacked wird... und das hat ja leider auch ganz gut funktioniert
Bei normalen Mediaplayer Herstellern kommt es eher auf die GUI und das Formathandling an um sich von der Konkurrenz abzusetzen und dafür reichen die in der Doku
beschriebenen Vendor Zertifikate vollkommen aus.... die uCodes sind eh für alle gleich, also hat da niemand Vorteile.

Ich habe leider keine Informationen gefunden, was genau durchgeführt wurde, als die UCodes versucht wurden zu laden.
Hat da jemand genauere Informationen darüber?

in der Doku gibts 3 Möglichkeiten die uCodes zu laden:
- Laden der uCodes per zBoot über ein romfs (so wie es auch alle NMT basierten player machen)
- Laden der uCodes per xrpc command aus einem laufenden Linux
- Laden per Kernelmodul konnte bisher nicht getestet werden, da wir das notwendige kernelmodul nicht hatte... das haben wir jetzt aus der Arcor IPTV box... wurde aber noch nicht getestet... ich mach mir da keine grossen Hoffnungen das es klappen wird.

beim Laden per xrpc bekommt man immerhin noch einen Fehlercode, aber da die auch nirgendwo in der Doku beschrieben sind, bringt der auch nicht viel.

[Hoernchen]

Der Fehlercode ist einfach nur Rückgabewert nr 9, "error" (definiert in rmstatus.inc)
Egal welche Möglichkeit man zum ucode-laden benutzt, es wird sowieso immer das Selbe per xrpc-Aufruf gemacht, mutex locken, dem xos die physische Adresse des xrpc-headers mitteilen, interrupt, warten, Rückgabewert auslesen, unlocken.

[pcgeil]

ist euch bei den Versuchen auch aufgefallen, dass z.B.
50xrpc_xload_vmlinux_ES4_prod.bin
mit xrpc geladen werden kann?

Die Datei 33xrpc_xload_dviinit_prod.bin kann auch erfolgreich geladen werden.

Die XTL Dateien welche im WinCE enthalten sind wohl xtask und die XTU die zu den xtask passenden unload Dateien.
Man kann diese erfolgreich mit xrpc laden, starten und beenden. Jedoch was es bringt :-( kein Plan.

Basiert die Arcor IPTV box auf Linux (wegen dem Modul) ?

[mce2222]

in den xrpc-daten steht im header um was es sich im payload handelt. abhängig davon werden die zugeordneten Zertifikate gecheckt.

es kommt also ganz auf die xrpc-daten an ob es klappt oder nicht.
solange keine "spezial zertifikate" in der cpu installiert sind gehts auch... aber bei den audio video ucodes sieht es schlecht aus.


ja die acror box ist linux basiert.... die hat nur das problem das dort überhaupt kein jtag port vorhanden ist, und das flash ist in nem BGA.... sehr unschön.

[pcgeil]

wie ist man dann an das modul von der Acror Box rangekommen?

Wurde schonmal probiert, mit yamon direkt das romfs zu laden? Weil hier probiert jemand das selbe auf einer nich gesperrten Tivx Box zu machen, also das Laden von Hand und er kann auch nur manches Laden.
http://www.binary-art.net/?p=245

Interessant wäre es, auf einer popcorn Box z.B. das WinCE von uns zu booten und danach zu sehen, ob auf der Box die "normalen" Linux Images noch funktionieren.
Wenns halt dumm läuft, ist die Box dann halt genauso viel Wert wie ne X300T :-)

[edit]
Ich mach mich vielleicht mit der Aussage unbeliebt, nur selbst wenn man alle CPU Unterlagen hat, ein DSP braucht eine Firmware. Bei einem Prozessor ist es ja genauso, er braucht ja auch den Maschinencode. Und wenn dieser nicht fest einprogrammiert ist, dann muss er irgendwann geladen werden!

[mce2222]

wie ist man dann an das modul von der Acror Box rangekommen?

der firmware update wird netter weise unverschlüsselt übers netz geschoben

Wurde schonmal probiert, mit yamon direkt das romfs zu laden? Weil hier probiert jemand das selbe auf einer nich gesperrten Tivx Box zu machen, also das Laden von Hand und er kann auch nur manches Laden.
http://www.binary-art.net/?p=245

mit nem yamon kann man romfs laden... nur gibts beim laden der ucodes fehler...

Interessant wäre es, auf einer popcorn Box z.B. das WinCE von uns zu booten und danach zu sehen, ob auf der Box die "normalen" Linux Images noch funktionieren.
Wenns halt dumm läuft, ist die Box dann halt genauso viel Wert wie ne X300T :-)

das wurde unwissentlich vor langer zeit mit einer x300t beta box gemacht... die hatte keinerlei vendor zertifikate installiert und hatte nur einen yamon im flash.
jetzt ist die box leider weniger wert als ne normale x300t, weil weder die ms iptv firmware noch linux oder sonstwas drauf läuft.... naja per modchip sollte linux noch laufen, aber das wurde nie bestätigt.

im bootloader (und ich meine auch in der tv2engine.dll) sind die vendor zertifikat install-xtasks enthalten.
wenn man also den bootloader startet dann checkt der als erstes ob die vendor zertifikate da sind... wenn nicht, dann werden sie installiert.

Ich mach mich vielleicht mit der Aussage unbeliebt, nur selbst wenn man alle CPU Unterlagen hat, ein DSP braucht eine Firmware. Bei einem Prozessor ist es ja genauso, er braucht ja auch den Maschinencode. Und wenn dieser nicht fest einprogrammiert ist, dann muss er irgendwann geladen werden!

unbeliebt machen für logisches denken ?? es ist schon der richtige ansatz. jetzt brauchst du NUR noch rausfinden wie dieser uCode in den DSP
kommt und dann mal weitersehen ...
Hoernchen hat sich genau mit dieser Frage schon eingehend beschäftigt und hat dabei noch nichts brauchbares gefunden.
aber wer weiss... je mehr leute drauf schauen, desto wahrscheinlicher ist das jemand das ganze durchschaut.

[pcgeil]

ok, nun bekomme ich langsam einen Überblick über das ganze.

Diese Vendor Zertifikate sind wohl mit dem Sigma Zertifikat geschützt. Ist es jener Schlüssel, welcher bei der Chipherstellung eingeprägt wird?
An welcher Adresse des Dumps befinden sich diese Vendor Zertifikate?
Verschlüsselung ist wohl leider 2048 Bit RSA  :-(

[edit]
Ist eigentlich bekannt, was genau die Ausgaben auf der UART Schnittstelle nach dem IPTV Bootloader unterdrückt?
Per Preprozessor wurde beim Compilieren nämlich ja nicht die Texte entfernt. Es werden ja auch laut den Texten verschiedene keys aus dem ext. Flash geladen.
Ich bin jedoch bei weitem noch nicht so weit, dass ich MIPS Assembler verstehen und deuten kann.

[Hoernchen]

Die Zertifikate sind im Seriellen Flash der XPU gespeichert auf die nur die XPU zugriff hat. Die Bootloaderausgabe klappt nicht weil soweit ich sehen kann die Ausgabefunktionen weggebastelt wurden ("nullsubs" in IDA).
Das die DSPs ohne ucodes nicht laufen ist mir eigentlich auch klar, aber alle Fakten sprechen leider gegen irgendwo versteckte ucodes, es gibt einfach nirgends genug Platz wo sie versteckt sein könnten, wenn man mal von Linux-ucode-Grössen ausgeht. Vielleicht sind die aber nur paar kB gross, da MS ja nicht alle möglichen Formate unterstützen muss, aber man kann halt schwer nach dem Unbekannten suchen...
Das das Laden bei der tvixbox nicht klappt hängt vermutlich damit zusammen das die ucodes bereits vom Bootloader geladen wurden und/oder die (bei uns 7 vorhandenen) Slots bereits alle belegt sind, laden kann er da nur den irqhandler und der wird direkt nach dem Laden "ausgeführt", ohne umwege über Slots. Generell werden nämlich auch ucodes die mehrfach verwendet werden (Audio DSP 0 und 1, Video Risc 0 und 1) nur einmal in einen Slot geladen und werden dann mehrfach auf den jeweiligen Hardwareteilen gestartet, gut möglich das man daher um nicht sinnlos Slots zu verschwenden generell einen ucode nicht mehrmals laden kann.
Der entsprechende teil aus der tvix-fw sieht so aus :

Code: [Select]

#executing xrpc...
cd /mruafw
MRUAFWDIR=/mruafw
#MRUAFWVER=RUA_2_8_2_branch_SNAPSHOT_2008-03-19_09h00m01Z_facsprod
MRUAFWVER=HEAD_SNAPSHOT_2008-05-01_07h00m01Z_facsprod
MRUAFWDTS=dts
xrpc -z
echo "xrpc $MRUAFWDIR/xrpc_xload_audio_ucode_SMP8634_$MRUAFWVER.mips.$MRUAFWDTS.bin"
xrpc $MRUAFWDIR/xrpc_xload_audio_ucode_SMP8634_$MRUAFWVER.mips.$MRUAFWDTS.bin
echo "xrpc $MRUAFWDIR/xrpc_xload_video_ucode_SMP8634_$MRUAFWVER.mips.bin"
xrpc $MRUAFWDIR/xrpc_xload_video_ucode_SMP8634_$MRUAFWVER.mips.bin
echo "xrpc $MRUAFWDIR/xrpc_xload_irq_handler_SMP8634_$MRUAFWVER.mips.bin"
xrpc $MRUAFWDIR/xrpc_xload_irq_handler_SMP8634_$MRUAFWVER.mips.bin
echo "xrpc $MRUAFWDIR/xrpc_xload_demux_ucode_SMP8634_$MRUAFWVER.mips.bin"
xrpc $MRUAFWDIR/xrpc_xload_demux_ucode_SMP8634_$MRUAFWVER.mips.bin
xrpc -ustart 2 4
xrpc -ustart 1 0
xrpc -ustart 1 1
xrpc -ustart 0 2
xrpc -ustart 0 3

[pcgeil]

also in der Acror Box, welche auf Linux basiert, sind die uCodes insgesamt nur 572kB groß. Wenn wir davon ausgehen, dass Microsoft noch weniger Formate unterstützt, kommen wir in die Region von 300 bis 400kB.
Der IRQ Handler ist 200kB groß und das Video uCode 315kB.
So langsam glaube ich wieder daran, dass es Platz im Flash hat, obwohl dieser nur 1MB groß ist.

Generelle Frage:
wenn ich z.B. das Xos von der Acror Box flashe, zerstöre ich damit meine Box?
Ok, einen wirklichen Vorteil davon werde ich sicherlich nicht haben, nur bin ich mir unsicher, ob auch das Xos Microsoft spezifisch sein muss, bzw. was passiert, wenn doch ein anderes geflasht wird. :-)


Wurde von einem gebooteten Linux eigentlich schonmal versucht, auf den mtdblock zuzugreifen und die einzelnen Bereiche auszulesen?
Gerade in Bezug auf den Boot splash romfs Bereich.

[Hoernchen]

Der irqhandler steckt in der booter.dll, das xos version Pe0 in der checkxos.exe, zumindest die "prod"-version mit dem standardcert die da drinsteckt ist identisch zu den Pe0-Updates die bei manchen Linuxboxen dabei sind. Die ersten 0x224 byte des zweiten enthaltenen xos identisch mit einem "dev"-xosMe0, das ist dann wohl für die "developA"-Boxen.
Sofern du also ein normales xos von einer Linuxbox hast wirst du das wohl benutzen können.
Was die mtd-Sache angeht, ja, ich hab so unter Linux bei mir gemütlich das Flash ausgelesen. Bringt halt nicht viel, ausser dem xenv und dem verschlüsselten bootloader und certs is da ja nix drin.

[pcgeil]

Bei der Acror Box ist doch im Flash ein romfs, welches die Mikrocodes enthält.
Auf jeden Fall wenn ich die upgrade.sh Datei richtig deute, wird das komplette romfs File direkt mit flashburn.sh in /dev/mtdblock/5 geschrieben.

Dann wird es wohl das romfs bei der X300T nicht geben. Der Flash ist ja auch deutlich kleiner :-/.

[Hoernchen]

Ach du meintest die Arcorbox... gibt doch ein Flashdump einer Betabox, man muss sich halt den kram per Hand rausfriemeln und mounten.