ucodes & co

[Hoernchen]

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.

[pcgeil]

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.

[Hoernchen]

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.

[pcgeil]

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.

[Hoernchen]

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.

[andi]

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?

Code: [Select]


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

[Hoernchen]

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.

[pcgeil]

@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

[mce2222]

die microcodes lassen sich leider nicht disassemblieren.... da die komplett verschluesselt sind.

[pcgeil]

Ü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.

[Hoernchen]

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

[pcgeil]

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

[asgard]

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

[pcgeil]

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.

[robert_s]

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.