bcache24.bmc und Cache0000.bin: das RDP-Cache-Format
Aufbau des RDP-Bitmap-Caches auf Byte-Ebene: Slots und 20-Byte-Header in bcache*.bmc, Interleaved RLE, Farbtiefen, Slot-Reste und das Format RDP8bmp.
Kurz gesagt. Ältere bcache*.bmc-Dateien haben keinen Dateiheader: Sie sind eine Folge von Slots fester Größe, jeder bestehend aus einem 20-Byte-Header (key1, key2, Breite, Höhe, Datenlänge, Flags) und einem Bereich für 64×64 Pixel mit 1, 2 oder 4 Byte pro Pixel. Die Zeilen laufen von unten nach oben; das Flag 0x08 kennzeichnet eine mit RDP-Interleaved-RLE komprimierte Kachel. Cache0000.bin und die folgenden Dateien beginnen mit RDP8bmp\0 und einer Version und enthalten danach unkomprimierte 32-Bit-Kacheln direkt hintereinander, jede hinter einem 12-Byte-Header, Zeilen von oben nach unten. Keines der beiden Layouts ist von Microsoft dokumentiert: Das Folgende beruht auf Reverse Engineering, vor allem durch bmc-tools der ANSSI, und ist das, was RDP Bitmap Cache Parser implementiert.
Wenn Ihnen das Artefakt neu ist, lesen Sie zuerst den Leitfaden zur RDP-Bitmap-Cache-Forensik.
Zwei Formate, ein Ordner
| Älterer BMC-Cache | Persistenter RDP-8-Cache | |
|---|---|---|
| Dateien | bcache2.bmc, bcache22.bmc, bcache24.bmc (bmc-tools nennt auch bcache23.bmc) | Cache0000.bin, Cache0001.bin, ... |
| Geschrieben von | Älteren Clients; auch auf aktuellen Systemen noch zu finden | Neueren Versionen des Clients |
| Dateiheader | Keiner | RDP8bmp\0 + u32-Version |
| Kacheldatensatz | 20-Byte-Header + fester Slot-Bereich für 64×64 | 12-Byte-Header + genau Breite×Höhe×4 Byte |
| Farbtiefe | 8, 16 oder 32 bpp je nach Datei | 32 bpp (B, G, R, X) |
| Zeilenreihenfolge | Von unten nach oben | Von oben nach unten |
| Kompression | Manche Kacheln, Interleaved RLE | Keine |
| Reste möglich | Ja | Nein (Datensätze sind lückenlos gepackt) |
Glossareinträge: bcache*.bmc, Cache*.bin.
Das ältere Format bcache*.bmc
Dateiname und Farbtiefe
Die Zahl im Namen verrät die Farbtiefe der Slots:
| Datei | Bit pro Pixel | Byte pro Pixel | Slot-Größe (20 + 64×64×Bpp) |
|---|---|---|---|
bcache2.bmc | 8 | 1 | 4.116 Byte |
bcache22.bmc | 16 | 2 | 8.212 Byte |
bcache24.bmc | 32 | 4 | 16.404 Byte |
Die Slot-Größen ergeben sich rechnerisch aus der unten beschriebenen Struktur; es sind keine zusätzlich dokumentierten Werte. bcache23.bmc wird von bmc-tools erwähnt; wir beschreiben die Datei hier nicht weiter.
Aufbau eines Slots
Es gibt keinen Dateiheader. Die Datei ist eine Folge von Slots, und jeder Slot beginnt mit einem 20-Byte-Header (0x14), Little Endian:
| Offset | Größe | Feld | Bedeutung |
|---|---|---|---|
0x00 | 4 | key1 | Erste Hälfte des Cache-Schlüssels |
0x04 | 4 | key2 | Zweite Hälfte des Cache-Schlüssels |
0x08 | 2 | width | Kachelbreite in Pixeln |
0x0A | 2 | height | Kachelhöhe in Pixeln |
0x0C | 4 | length | Länge der folgenden Kacheldaten |
0x10 | 4 | flags | Bit 0x08: komprimiert |
Nach dem Header folgt der Slot-Bereich mit 64×64×Byte-pro-Pixel, unabhängig von der tatsächlichen Kachelgröße. Eine 64×64-Kachel füllt ihn aus; eine 16×64-Kachel am Bildschirmrand nutzt nur einen Teil davon.
Die Feldnamen sind beschreibend, nicht offiziell. Entscheidend ist, dass key1 und key2 zusammen den 64-Bit-Schlüssel der Bitmap bilden.
Unkomprimierte Kacheln
Ist das Flag 0x08 nicht gesetzt, sind die Daten rohe Pixel. Die Byte pro Pixel ergeben sich aus length ÷ (width × height). Die Zeilen sind wie bei einer BMP von unten nach oben gespeichert; ein Decoder muss sie also umdrehen.
Ein Detail, das beim Vergleich von Werkzeugen wichtig ist: bmc-tools nimmt im Slot eine Zeilenlänge (Stride) von 64 Pixeln an. RDP Bitmap Cache Parser verwendet bei Kacheln, die schmaler als 64 Pixel sind, die eigene Breite der Kachel als Stride. Bei solchen Kacheln können die beiden Werkzeuge unterschiedliche Bilder erzeugen; wirkt eine schmale Kachel in einem Werkzeug verzerrt, versuchen Sie das andere.
Komprimierte Kacheln: Interleaved RLE
Ist das Flag 0x08 gesetzt (bmc-tools behandelt dieses Bit als Kompressions-Flag; die Bedeutung ist erschlossen, für diese Datei nicht dokumentiert), sind die Daten mit dem RDP-Bitmap-Codec Interleaved RLE komprimiert. Dieser Codec ist dokumentiert, in MS-RDPBCGR, Abschnitt 2.2.9.1.1.3.1.2.4. Komprimierte 32-Bit-Kacheln können auch den Planar-Codec von RDP 6.0 verwenden, der in MS-RDPEGDI dokumentiert ist; bmc-tools überspringt diese Kacheln, RDP Bitmap Cache Parser dekodiert sie.
Der Datenstrom ist eine Folge von Orders. Jede Order hat eine reguläre Form, eine „Lite“-Form und für lange Läufe eine „Mega-Mega“-Form. Die Familien:
| Order-Familie | Was sie kodiert |
|---|---|
| Background Run | Pixel aus der Zeile darüber kopieren (schwarz in der ersten Zeile) |
| Foreground Run | Pixel der Zeile darüber XOR eine Vordergrundfarbe (in der ersten Zeile die Farbe selbst) |
| FG/BG Image | Eine Bitmaske, die zwischen den beiden obigen Fällen wählt |
| Color Run | Eine wiederholte Farbe |
| Color Image | Literale Pixel |
| Dithered Run | Zwei abwechselnde Farben |
| White / Black | Ein einzelnes weißes oder schwarzes Pixel |
Weil Background Runs auf die vorherige Zeile verweisen, kann ein einziges beschädigtes Byte den Rest der Kachel verschmieren. Eine Kachel, die der Decoder nicht vollständig dekomprimieren kann, wird im Werkzeug als „Nicht dekodiert“ markiert, statt geraten zu werden.
8-Bit-Kacheln und die Palette
Die Palette einer 8-Bit-Sitzung wird nicht im Cache gespeichert. Decoder, bmc-tools und unserer eingeschlossen, verwenden eine Standardpalette von Windows, die Farben sind also nur näherungsweise richtig. Text und Fensterformen bleiben meist lesbar; ziehen Sie keine Schlüsse aus den genauen Farben einer 8-Bit-Kachel.
Slot-Reste
Slots haben eine feste Größe und werden wiederverwendet. Wird eine kleinere Kachel in einen Slot geschrieben, der vorher eine größere enthielt, kann der ungenutzte Teil des Slots noch Pixel der alten Kachel enthalten. Dieser Rest ist ein Slot-Rest.
Slot-Reste zählen: Sie können die einzige erhaltene Spur von etwas sein, das früher auf dem Bildschirm war. Im fiktiven Beispiel, das mit dem Werkzeug ausgeliefert wird, enthält ein Slot in bcache22.bmc noch den oberen Teil einer älteren Kachel: die Titelleiste eines Editorfensters mit creds.txt, einer Datei, die auf dem entfernten Host angelegt und später gelöscht wurde.
bmc-tools exportiert Reste mit -o / --old. RDP Bitmap Cache Parser zeigt sie neben den regulären Kacheln an, markiert als „Slot-Rest“. Ein Rest ist ein Fragment eines älteren Bildes, keine vollständige Kachel: Sagen Sie das, wenn Sie einen berichten.
Das Format Cache*.bin von RDP 8
Neuere Versionen des Clients schreiben Cache0000.bin, Cache0001.bin und so weiter. Der Aufbau ist einfacher.
Dateiheader
| Offset | Größe | Feld |
|---|---|---|
0x00 | 8 | Magic RDP8bmp\0 |
0x08 | 4 | Version (u32) |
Kacheldatensätze
Die Kacheln folgen direkt hintereinander bis zum Dateiende:
| Offset im Datensatz | Größe | Feld |
|---|---|---|
0x00 | 4 | key1 |
0x04 | 4 | key2 |
0x08 | 2 | width |
0x0A | 2 | height |
0x0C | width×height×4 | Pixel, B, G, R, X, Zeilen von oben nach unten |
Keine Kompression, kein Längenfeld (die Größe folgt aus Breite und Höhe), kein Auffüllen von Slots. Die Datensätze sind lückenlos gepackt, es gibt also keine Reste im obigen Sinne.
Was keines der Formate speichert
| Fehlt | Folge |
|---|---|
| Zeitstempel | Sitzungen mit anderen Artefakten datieren (Artefakte auf dem Quellsystem) |
| Bildschirmkoordinaten | Bildschirme müssen nach Augenmaß rekonstruiert werden (Rekonstruktion) |
| Kennungen von Sitzung oder Ziel | Zuordnung zu einem Ziel über Protokolle und Registry, nicht über den Cache |
| Duplikate | Identische Teile werden einmal zwischengespeichert |
Was der Parser pro Kachel zeigt
Für jede Kachel listet das Detailfenster von RDP Bitmap Cache Parser Cache-Schlüssel, Breite und Höhe, Farbtiefe, Kompression und Datei-Offset auf, sodass Sie jede Kachel mit einem Hex-Editor oder mit der Ausgabe von bmc-tools abgleichen können. Wie sich die Werkzeuge unterscheiden, zeigt RDP-Cache-Parser im Vergleich.
FAQ
Ist das Dateiformat des RDP-Bitmap-Caches von Microsoft dokumentiert?
Nein. Der Aufbau von bcache*.bmc und Cache*.bin ist durch Reverse Engineering bekannt, vor allem durch bmc-tools der ANSSI. Dokumentiert sind nur die Bitmap-Codecs in komprimierten .bmc-Kacheln: Interleaved RLE in MS-RDPBCGR und, bei 32-Bit-Kacheln, der Planar-Codec von RDP 6.0 in MS-RDPEGDI.
Was ist der Unterschied zwischen bcache22.bmc und bcache24.bmc?
Die Farbtiefe der Slots: bcache22.bmc enthält 16 Bit pro Pixel, bcache24.bmc 32 Bit pro Pixel. bcache2.bmc enthält 8 Bit pro Pixel.
Warum haben manche Kacheln falsche Farben?
Meist handelt es sich um 8-Bit-Kacheln. Die Palette der Sitzung wird nicht im Cache gespeichert, Decoder greifen daher auf eine Standardpalette von Windows zurück, und die Farben sind nur näherungsweise richtig. Formen und Text bleiben in der Regel lesbar.