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 ?!
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 (http://www.lundman.net/wiki/index.php/NMT:firmware)
Kennt ihr bestimmt schon, dachte es könnte helfen...
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.
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?
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.
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.
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...
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 ?
Das Pinout is bekannt, da lässt sich nichts mit anfangen.
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 ?
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.
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.
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.
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.
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.
Möglich wäre es, die Frage ist nur woher dieses ucodes kommen sollen, sofern die sich grössenmässig nicht total von den Linux-ucodes unterscheiden würden sie nichtmal in den Flash woder BL rumhängt passen.
Aber was für einen Sinn hätte sonst irgendwelche Meldungen im Flash?
Ich mein WinCE wird doch nicht auf das Flash zurückgreifen.
Ich bin jedoch noch nicht durchgestiegen, welche Funktion überhaupt es aufrufen könnte.
Auch weiß ich ehrlich gesagt nicht, ob so eine Meldung auf der UART ausgegeben werden würde. Wobei wohin soll es sonst geschrieben werden?
In dem Flash ist ja auch eine URL für die certs angegeben. Weiß jemand welche Bedeutung dies hat?#
[EDIT]
also, man sieht doch am Anfang vor dem eigentlichen Laden des NK.BIN Files ein T-Online Logo, oder?
Ich kann es leider gerade nicht prüfen.
Wenn das so wäre, dann muss doch zwangsläufig der Mikrocode für den VIDEO DSP schon geladen sein.
Wie verhält sich eine Popcorn Hour Box, wenn Sie kein System findet?
Weiß das zufällig einer?
Oder auch anders herum gefragt, eine Ausgabe über HDMI kann doch erst erfolgen, wenn irgendein Microcode in den DSP geladen wurde. Ansonsten dürfte da nix kommen.
::)
Das Bitmap wird beim zboot zwar in der Regel nach allen ucodes geladen, ich bin mir aber nicht sicher ob das nicht auch ohne ucodes funktioniert. Irgendwelche verdächtigen xrpc-Aufrufe liessen sich nicht finden, und mir ist ausser per XRPC_ID_XLOAD keine Möglichkeit bekannt die ucodes zu laden. Kann natürlich sein das IDA da mal wieder relevante Sachen unterschlägt.
ich hab leider keine Ahnung ob bislang die BMP Files aus dem Flash extrahiert wurden und ob die Adresse identifiziert wurde.
Jedoch habe ich heute Abend mal mich drangemacht und aus dem Flash die BMPs extrahiert.
Es gibt insgesamt 4 BMP Bilder welche allesamt mit inflate (zlib) gepackt sind.
Ich hab ein kleines Pythonskript modifiziert, welches den DUMP durchgeht und die Bilder extrahiert.
Die Inflate Dateien fangen an bei:
1. 0x69bac - entspricht dem Zahnrad
2. 0x6a05c - rotes Kreutz
3. 0x6a3f4 - Punkte
4. 0x6a6d4 - Connect? (Standartbild nach einem Cold Start)
Ich werde das Skript noch ein bissel modifizieren und dann falls es gewünscht ist, hier hochladen.
Aufmerksam auf inflate bin ich geworden, weil im Dump inflate 1.14 von Mark Adler erwähnt wird.
Vielleicht hilft dies schonmal, die Stelle zu identifizieren, welche mit dem DSP kommuniziert. Ok zuerst muss inflate aufgerufen werden.
Hm, ein inflate-Aufruf fiel mir bisher nie auf, aber nun wo dus erwähnst... da müsste man mal schauen was dann mit dem entpackten Bildchen passiert.
Hi,
also die ucodes werden nur zum demuxen und dekodieren von den audio/video strömen benötigt! Zumindest bei den Linux boxen ist es so, das für diesen splashscreen keine ucodes benötigt werden (obwohl sie in einem rutsch mitgeladen werden). man brauch nur das bild als binary und den irqhandler. bei dvi/hdmi zusätzlich noch das bild (in höherer auflösung) und ein zboot-applet, welches den digitalen output initialisiert! das sollte es gewesen sein!
In Linux sind die gesamten ucodes ca. 2mb groß. die würden also gar nicht in den flash passen.
ich kenn mich mit wince gar nicht aus und mach damit auch nix, aber evtl. hilft es ja sich die multimedia driver mal anzugucken und auch bzgl. dateigröße zu vergleichen. dazu hier einige infos, gibts denn diese dateien im windows ce überhaupt?
The current SDK provides a set of "multimedia" drivers in binary form only. The drivers are:
1. SMP863x.dll - This is a windows ce built-in driver. This driver must be installed for any other driver to work.
2. TSDEMUX.dll - This is a direct show transform filter. It is a pure software demux that allows the playback of transport streams.
3. DDI_86xx.dll - This is a standard windows ce GDI driver.
4. HDMI863x.dll - This is a helper DLL used by the GDI driver to support HDMI output.
5. DS863x.dll - This is a direct show renderer filter. It connects to the tsdemux filter or the standard microsoft ASF source filter to render the video and audio streams.
6. DSWMAPPRO.DLL - This is a helper DLL used the direct show renderer filter to render WMA pro audio streams.
7. WAVE863x.DLL - This is a standard windows CE wave driver. It allows an application to play PCM sounds using the wave interface. This driver is optional, and should only be installed if your application requires simple "UI" sounds.
Viele Grüße
Andi
Gibt bei uns keine der DLLs, Microsoft hat wohl mehr infos über die Box als alle anderen Hersteller und verzichtet komplett auf irgendwelchen fertigen libs, daher gibts weder gbus noch sonstwas, die dlls spielen allesamt direkt an der Hardware herum.
@andi
gut, wenn das so ist, dann war meine Vermutung falsch.
Der IRQ Handler muss dann jedoch im Flash liegen. Der entpackte IRQ Handler von der NMT Firmware ist
( 33xrpc_xload_irq_handler_SMP8634_2.7.176sybs.dtspass2_GCC4_facsprod.bin )
immerhin 176kb groß. Wäre also auch verdammt viel für den 1MB Flash.
Einen gzip Header habe ich im Dump jedoch nicht gefunden.
Die Mikrocodes der NMT Firmware haben sich zwischen Januar und heute, ein bisschen verändert. Der IRQ Handler wohl nicht, aber Video und Audio sind von der Größe her unterschiedlich.
Wenn ich die Mikrocodes disassemblieren möchte, welchen CPU stell ich dann ein? Ist ja ein DSP, wobei im Dateinamen schon erwähnt wird, dass GCC4 zum kompilieren eingesetzt wurde.
Wenn man die NK.bin zerlegt, dann findet man ja fast keine Datei, welche die Mikrocodes beinhalten kann, allein von der Dateigröße.
Microsoft muss doch auch Mikrocodes laden, welche als bin oder sonst einem Format vorliegen, sonst würde der DSP murks machen.
Die Microcodes der NMT Firmware haben wohl einen 0x20 Header:
Für
video_ucode kommt dann: 3a 00 03 07
audio_ucode kommt dann: 3b 00 04 07
demux_ucode kommt dann: 3c 00 05 07
irq_handler kommt dann: 3d 00 06 07
die microcodes lassen sich leider nicht disassemblieren.... da die komplett verschluesselt sind.
Über die 8 bytes sollte man aber immerhin die mikrocodes finden.
Ich stell vielleicht im Moment ein paar viele Fragen, die möglicherweise alt sind, doch ich find dazu keine Informationen.
Wie unterbindet der Microsoft Bootloader die Ausgabe über UART?
Weil die ganzen Texte stehen immer noch im Flash!
[EDIT:]
Nun ich hab gerade den DUMP mit den
XTLApp_1.2_XosE0.bin
XTLBoot.bin
XTUApp_1.2_XosE0.bin
XTUBoot.bin
verglichen.
Also bei allen diesen Dateien auf der HardDisk ist der Bereich von 0x00 bis 0x203 identisch.
Bei XTUBoot.bin
und XTUApp_1.2_XosE0.bin ist zudem noch 0x204 bis 0x303 identisch.
Die Dateien in der NK.bin stimmen aber nicht mit den 4 anderen Dateien überein. Jedoch sind bei beiden Dateien im NK.bin von 0x00 bis 0x203 identisch.
Der Dump des Bootloaders hat die ersten 0x204 auch enthalten. Und zwar die Anfangssellen lauten:
0x6b9b4 und 0x6cb0c
Der Rest stimmt also weder mit den von der Harddisk noch mit den zwei Dateien der NK.bin überein.
Deshalb weiß ich auch nicht, wie weit die Dateien gehen.
Zudem habe ich noch die NMT Firmware untersucht. Also bei Demux und IRQ_Handler stimmen bei drei unterschiedlichen Firmwares die ersten 0x324 überein. Wobei die ersten 0x20 sich unterscheiden, da es wohl Hashwerte sind.
Komischerweise habe ich bei Audio keine Übereinstimmung festgestellt.
Jedoch bei vmlinux und dvinit_prod stimmen die ersten 0x224 überein (abzüglich des 0x20 Hashwerts).
Wenn ich das so vergleiche sieht es doch aus, als ob da ein Schema dahintersteckt.
Die ersten 0x20 Byte der ucodes sind die xrpc_block_header struct in der wohl historisch bedingt param0 die vorab-Ladeadresse an die der Xloadkram kopiert wird bevor dem XOS bescheid gesagt wird enthält, danach folgen mindestens 0x204 Byte des Certs für den jeweiligen ucode. Alles weitere ist unbekannt, weils nur für das xos relevant ist und daher nirgends im bekannten Code erwähnt wird. An dieser Stelle mal ein *hust* : wiki (http://www.t-hack.com/wiki/index.php/XRPC)
Ich habe im Wiki eine Seite zu den Bildern im Bootloader eingerichtet.
Jedoch kann ich nicht das gezippte Python Skript anhängen, obwohl es im zip Format ist.
Kann das einer der Admins bitte fixen?
Danke
Hi,
Ich habe im Wiki eine Seite zu den Bildern im Bootloader eingerichtet.
Jedoch kann ich nicht das gezippte Python Skript anhängen, obwohl es im zip Format ist.
man konnte es nicht hochladen, da das Wiki da wohl einen Bug hat...Das Problem war der Dateiname des ZIP-Archives "zlib-decrypt.py.zip".
So "zlib-decrypt_py.zip" hats bei mir funktioiniert ;)
Kann das einer der Admins bitte fixen?
Danke
Erledigt!
http://www.t-hack.com/wiki/index.php/Pictures_inside_bootloader
Viele Grüße
Asgard
Viele Grüße
da wird dann wohl der string nicht richtig geparst. :-)
Ok danke. Nächstes Mal werde ich daran denken.
Falls jemand eine Version ungleich 1051 hat vom Bootloader, so fände ich es ganz gut, mal zu schaun, ob die Bilder an der selben Stelle vorhanden sind.
In dem beta_dump aus dem Wiki, sind wohl keine Archive enthalten.
Falls jemand eine Version ungleich 1051 hat vom Bootloader, so fände ich es ganz gut, mal zu schaun, ob die Bilder an der selben Stelle vorhanden sind.
Bootloader V1039:
0x00067bac . 1192 --> 307396
0x0006805c . 909 --> 307400
0x000683f4 . 727 --> 307376
0x000686d4 .. 4064 --> 307826
Bootloader V1053:
0x0006bbac . 1192 --> 307396
0x0006c05c . 909 --> 307400
0x0006c3f4 . 727 --> 307376
0x0006c6d4 .. 4064 --> 307826
Die extrahierten Dateien sind in allen drei Bootloaderversionen identisch.
Vielen Dank fürs Überprüfen.
Die letzten drei Hexzahlen stimmen überein.
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?
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 :/
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.
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.
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) ?
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.
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!
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.
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.
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 :
#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
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.
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.
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 :-/.
Ach du meintest die Arcorbox... gibt doch ein Flashdump einer Betabox, man muss sich halt den kram per Hand rausfriemeln und mounten.
ne ne :-) ich meinte, ob es das romfs auch bei der X300t gibt.
Dass es die Acror Box hat, das weiß ich.
Nö, wie gesagt, xenv, bootloader, certs, nochmal xenv, das wars.
Nur mal so eine Idee ? ? ? ?
Wenn man während des Bootvorganges die CPU kurzzeitig auserhalb der Spezifikation betreibt (gepulste Unterschreitung der Betriebspannung oder ähnlich)
könnte es doch passieren das einige Befehle übersprungen oder gar nicht richtig ausgeführt werden. In diesen Falle wären die Logs ganz interessant. Es ist eine ziemliche Glücksache. Dieses Verfahren hatte bei Smarten Karten :P ;D ;) vor Jahren zum Erfolg geführt. Ich habe derzeit leider :'( keine Möglichkeit dieses Auszuprobieren. Es ist halt nur eine Idee. Vielleicht hilft es uns ja weiter.
gruß sirius01 :) 8) :)
Geht nicht, das ist nicht nur eine CPU, ich würde dann den gesamten SOC ins Chaos stürzen so das überall irgendwas passiert. Um das selektiv nur bei der XPU zu machen müsste ich ja den Chip decappen, wenn jemand die Mögichkeit hat direkt am Chip rumzuspielen könnte derjenige aber auch gleich direkt die Hardware angreifen.
also das direkt an der Hardware rum manipulieren ...
man müsste ja zuerst mal den kunstoff entfernen und dann anfangen, die einzelnen bereiche zu identifizieren
aber das blöde dabei ist ja, man kann den smp8634 Prozessor nicht bei den gänigen Distributoren kaufen. Also geht für jeden Versuch eine Box drauf.
Also wie man prinzipiell vorgeht, das weiß ich :-)
Hab vor kurzem ein CMOS NAND Gatter mit ESD Test gestresst und dann optisch überprüft, was genau kaputt gegangen ist.
Das PDIP Gehäuse haben wir sehr einfach entfernt gebracht ;D
Nur dürfte der Chip allein von der Struktur meilenweit heftiger sein.
Wenn man es richtig macht, dann funktioniert ja der Chip noch, obwohl der Waver frei gelegt ist.
Klar kann man das machen, wenn man halt die nötige Ausrüstung und vor allem Zeit hat. Würde mich auch mal interessieren wie sicher denn die Hardware selbst ist, denn die besteht ja eigentlich "nur" aus einer Hand voll erworbener Hard- und Soft-IP-Cores (MIPS, ..) und viel glue logic dazwischen. Bei den meissten Leuten mit entsprechenden Kenntnissen und Ausrüstung scheiterts halt am Zeitaufwand.
..Und es gibt es gibt doch neues.
Ich ging ja bisher immer davon aus das die wince ucodes im xloadformat vorhanden sind, was aber wohl falsch war. Nach mehreren genaueren Blicken auf die libprivate.a aus mrua 2.8.0.1 (auf der Suche nach macrovision & hdcp ;)) fiel mir auf das dort auch nur der irqhandler als xload eingebettet ist, alle anderen ucodes aber ein sehr seltsames Format das keine Ahnlichkeit mit den xrpc ucodes hat besitzen. Ich gehe nun also davon aus das in wince sehr wohl die ucodes in den dlls herumliegen, aber man (= ich mit xrpc scanner) sie halt bisher nie gefunden hat da das Format völlig anders ist. Leider muss ich zugeben das mein mips-assembler dann doch nicht ausreicht um die ucode-ladefunktion aus der libprivate wirklich zu verstehen ohne mehr zu raten und zu vermuten (nicht zuletzt dank unaligned access und damit verbundenem instruktionschaos und halfwordgetausche), wäre also gut wenn sich das mal einer anschaut...
Das hört sich doch schonmal ganz vielversprechend an :)
@Hoernchen
Wie hast du die ucodes in der libprivate.a lokalisiert?
Bzw. gibt es auch einen Header, nach dem man suchen kann?
Die ucodes selber sind relativ einfach zu finden, libprivate.a ist ein bzw mehrere "ar"-Archive, nach dem Entpacken (siehe topic "libprivate.a & IDA and mips elf....") kann man einfach den Dateinamen und -grösse folgen ;)
Am sinnvollesten ist der Blick in libemhwlib.a_libmodules.a_AudioEngine.o, funktion set_Microcode, dort sieht man direkt den verweis auf audio_microcode_tango2_bin in der data section wo dann der ucode beginnt, dank diesem unauffälligen Namen erkennt man die ucodes & co auch sonst immer leicht. Diese Funktion ruft dann erstmal ucode_load_microcode aus der libemhwlib.a_libmodules.a_libucodeinterface.a_ucode_load_microcode.o auf, vorsicht, die relevantesten Argumente werden dem Stack übergeben, man muss also mal kurz herumrechnen.
Man muss das alles einmal selber nachvollziehen und anhand von
DCCSP(pDCC->pRUA, audio_engine0, RMAudioEnginePropertyID_Microcode, &audio_ucode, sizeof(audio_ucode));in mrua_SMP8634_2.8.0.1_dev.mips\MRUA_src\dcc\src\dcc.c den Ablauf samt übergebener structs verfolgen.
Tipps:
- audio_ucode.Address = 0;
- DCCSP ist im ein komplexes makro was aber auch nur auf RuaSetProperty hinausläuft, siehe dazu http://www.t-hack.com/wiki/index.php/RUA.
- Allgemein existieren alle gbusfunktionen aus mrua nur im Kernel selber, als
RMuint32 gbus_read_uint32(struct gbus *pgbus, RMuint32 byte_address)
void gbus_write_uint32(struct gbus *pgbus, RMuint32 byte_address, RMuint32 data)
d.h. bei einem Aufruf ist zum Nachvollziehen einzig und allein relevant was in $a1 und danach in $v0 bzw zum schreiben in $a1 und $a2 steht weil
- die gbusstruct in $a0 die durch ganz mrua mitgeschleift wird kann man meisst völlig ignorieren.
iptvplatform.dll:
audio_microcode_tango2_bin: .data:01D4C464
video_microcode_tango2_bin: .data:01E29100
crc_microcode_tango2_bin: .data:01E772FC
sha1consumer_tango2_demux_bin: .data:01E7FFAC erkennbar am padding, dem traurigen chinesensmiley ¦(
streamcapture_microcode_tango2_bin: .data:01E7FC88
xcrc_microcode_tango2_bin: .data:01E7EFC4 erkennbar am padding, 0xDEADFACE
demuxpsf_microcode_tango2_bin: .data:01E77B24
funktion ucode_load_microcode beginnt bei .text:02E22354
Nun müsste sich halt nur noch wer mit der Ladefunktion auseinandersetzen ;)
sehr schön... damit können wir uns nun ein linux kernel modul zusammenbauen das auf der x300t funktionieren wird (das ist der leichte teil)
die echte Herausforderung wird dann aber sein die API zu rekonstruieren.
hoffen wir mal das die nicht allzugrosse Änderungen im Vergleich zu der Linux API hat, wo wir die sourcen haben.
Das Pinout is bekannt, da lässt sich nichts mit anfangen.
wo findet man das? selbst wenn man nichts damit anfangen kann, würds mich interessieren.
http://narf.pastebin.com/m5ff29a84
Ich fange gerade erst an, mich mit dieser Box auseinander zu setzen, darum erschlagt mich bitte nicht gleich, wenn meine Idee schonmal wo genannt wurde oder abwegig ist ;)
So wie ich das noch von meinen diversen Recherchen zu embedded Linux Geräten weiss, gibt es immer wieder den Ansatz, dass man, wenn man Hardwareteile nicht aktiviert bekommt, lädt man über einen kexec ähnlichen Bootloader einen Kernel, nachdem das originale Betriebssystem diese Teile aktiviert hatte.
Vielleicht ist dies hier ja auch möglich...
Zwar nicht ganz an die uCodes gekommen, aber vielleicht ist die Hardware nutzbar.
Das Problem sind nun weniger die ucodes als viel mehr die Kommunikation die grösstenteils via IRQ-Handler stattfindet, da dieser WinCE-spezifisch ist hab ich also bestenfalls einen zwar prinzipiell funktionierenden Chip bei dem ich aber keine Ahnung habe wie ich ihn benutzen soll. Sieht alles nich so gut aus...
Kann man nicht das WinCE so modifizieren das es nur noch die Funktion hat die Ucodes auszuführen und als Kommunikationsschnittstelle zwischen den Linuxkernel dient.
das wince führt die uCodes nicht aus. es lädt diese nur in die CoProzessoren bzw. DSPs.
aber wie Hörnchen schon geschrieben hat... das bringt gar nichts solange man die DSPs nicht korrekt mit Daten versorgen kann.
Leider ändert SigmaDesigns gerne mal etwas an der API zu den CoProzessoren, daher würde es nur funktionieren, wenn:
1. wir wüssten welche uCode version in unserem WinCE verwendet wird
2. wir die Linux kernel module mit der gleichen version hätten
soweit ich weiss gibt es keine Möglichkeit die version der uCodes herauszufinden :(