bcache24.bmc et Cache0000.bin : format du cache RDP
Le cache bitmap RDP octet par octet : emplacements bcache*.bmc et en-têtes de 20 octets, RLE entrelacé, profondeurs de pixel, restes d'emplacement et format RDP8bmp.
En bref. Les anciens fichiers bcache*.bmc n'ont aucun en-tête de fichier : ce sont une suite d'emplacements de taille fixe, chacun composé d'un en-tête de 20 octets (key1, key2, largeur, hauteur, longueur des données, flags) suivi d'une zone de 64×64 pixels à 1, 2 ou 4 octets par pixel. Les lignes sont stockées de bas en haut ; le flag 0x08 signale une tuile compressée en RLE entrelacé RDP. Cache0000.bin et ses voisins commencent par RDP8bmp\0 et un numéro de version, puis enchaînent des tuiles 32 bits non compressées, chacune précédée d'un en-tête de 12 octets, lignes de haut en bas. Aucune de ces deux structures n'est documentée par Microsoft : ce qui suit vient de la rétro-ingénierie, surtout celle de bmc-tools de l'ANSSI, et c'est ce qu'implémente RDP Bitmap Cache Parser.
Si vous découvrez cet artefact, commencez par le guide d'analyse forensique du cache bitmap RDP.
Deux formats, un seul dossier
| Ancien format BMC | Cache persistant RDP 8 | |
|---|---|---|
| Fichiers | bcache2.bmc, bcache22.bmc, bcache24.bmc (bmc-tools mentionne aussi bcache23.bmc) | Cache0000.bin, Cache0001.bin, ... |
| Écrit par | Les anciens clients ; on le trouve encore sur des systèmes récents | Les versions plus récentes du client |
| En-tête de fichier | Aucun | RDP8bmp\0 + version u32 |
| Enregistrement de tuile | En-tête de 20 octets + zone d'emplacement fixe de 64×64 | En-tête de 12 octets + exactement largeur×hauteur×4 octets |
| Profondeur de pixel | 8, 16 ou 32 bpp selon le fichier | 32 bpp (B, G, R, X) |
| Ordre des lignes | De bas en haut | De haut en bas |
| Compression | Certaines tuiles, RLE entrelacé | Aucune |
| Restes possibles | Oui | Non (enregistrements contigus) |
Entrées du glossaire : bcache*.bmc, Cache*.bin.
L'ancien format bcache*.bmc
Nom de fichier et profondeur de pixel
Le nombre dans le nom indique la profondeur des emplacements :
| Fichier | Bits par pixel | Octets par pixel | Taille d'emplacement (20 + 64×64×Bpp) |
|---|---|---|---|
bcache2.bmc | 8 | 1 | 4 116 octets |
bcache22.bmc | 16 | 2 | 8 212 octets |
bcache24.bmc | 32 | 4 | 16 404 octets |
Ces tailles se déduisent simplement de la structure décrite plus bas ; ce ne sont pas des valeurs documentées par ailleurs. bcache23.bmc est mentionné par bmc-tools ; nous n'en disons pas plus ici.
Structure d'un emplacement
Il n'y a pas d'en-tête de fichier. Le fichier est une suite d'emplacements, et chaque emplacement commence par un en-tête de 20 octets (0x14), en little-endian :
| Offset | Taille | Champ | Signification |
|---|---|---|---|
0x00 | 4 | key1 | Première moitié de la clé de cache |
0x04 | 4 | key2 | Seconde moitié de la clé de cache |
0x08 | 2 | width | Largeur de la tuile en pixels |
0x0A | 2 | height | Hauteur de la tuile en pixels |
0x0C | 4 | length | Longueur des données de tuile qui suivent |
0x10 | 4 | flags | Bit 0x08 : compressée |
Après l'en-tête vient la zone de l'emplacement, de 64×64×octets par pixel, quelle que soit la taille réelle de la tuile. Une tuile de 64×64 la remplit ; une tuile de 16×64 en bord d'écran n'en occupe qu'une partie.
Les noms de champs sont descriptifs, pas officiels. L'essentiel : key1 et key2 forment ensemble la clé 64 bits du bitmap.
Tuiles non compressées
Quand le flag 0x08 n'est pas positionné, les données sont des pixels bruts. Le nombre d'octets par pixel vaut length ÷ (width × height). Les lignes sont stockées de bas en haut, comme dans un BMP : le décodeur doit donc les retourner.
Un détail à connaître quand on compare les outils : bmc-tools suppose un pas de ligne (row stride) de 64 pixels dans l'emplacement. RDP Bitmap Cache Parser utilise la largeur propre de la tuile comme pas de ligne pour les tuiles de moins de 64 pixels de large. Sur ces tuiles, les deux outils peuvent produire des images différentes ; si une tuile étroite paraît cisaillée dans l'un, essayez l'autre.
Tuiles compressées : RLE entrelacé
Quand le flag 0x08 est positionné (bmc-tools traite ce bit comme l'indicateur de compression ; sa signification est déduite, et non documentée pour ce fichier), les données sont compressées avec le codec bitmap RLE entrelacé (interleaved RLE) de RDP. Ce codec, lui, est documenté, dans la section 2.2.9.1.1.3.1.2.4 de MS-RDPBCGR. Les tuiles 32 bits compressées peuvent aussi utiliser le codec planar de RDP 6.0, documenté dans MS-RDPEGDI ; bmc-tools ignore ces tuiles, alors que RDP Bitmap Cache Parser les décode.
Le flux est une suite d'ordres. Chaque ordre existe sous une forme normale, une forme « lite » et, pour les longues séquences, une forme « mega-mega ». Les familles :
| Famille d'ordres | Ce qu'elle encode |
|---|---|
| Background run | Copie des pixels de la ligne du dessus (noir sur la première ligne) |
| Foreground run | Pixel de la ligne du dessus XOR une couleur de premier plan (la couleur elle-même sur la première ligne) |
| FG/BG image | Un masque de bits qui choisit entre les deux cas précédents |
| Colour run | Une couleur répétée |
| Colour image | Des pixels littéraux |
| Dithered run | Deux couleurs en alternance |
| White / black | Un seul pixel blanc ou noir |
Comme les background runs font référence à la ligne précédente, un seul octet corrompu peut baver sur tout le reste de la tuile. Une tuile que le décodeur ne parvient pas à décompresser entièrement est marquée Non décodée dans l'outil, plutôt que devinée.
Tuiles 8 bits et palette
La palette d'une session 8 bits n'est pas stockée dans le cache. Les décodeurs, bmc-tools comme le nôtre, utilisent une palette Windows par défaut : les couleurs sont donc approximatives. Le texte et la forme des fenêtres restent en général lisibles ; ne tirez aucune conclusion des couleurs exactes d'une tuile 8 bits.
Restes d'emplacement
Les emplacements ont une taille fixe et sont réutilisés. Quand une tuile plus petite est écrite dans un emplacement qui contenait auparavant une tuile plus grande, la partie inutilisée peut encore contenir des pixels de l'ancienne tuile. Ce résidu est un reste d'emplacement.
Ces restes comptent : ils peuvent être la seule trace survivante de quelque chose qui était à l'écran plus tôt. Dans l'exemple fictif fourni avec l'outil, un emplacement de bcache22.bmc contient encore le haut d'une tuile plus ancienne : la barre de titre d'une fenêtre d'éditeur ouverte sur creds.txt, un fichier créé puis supprimé sur l'hôte distant.
bmc-tools exporte les restes avec -o / --old. RDP Bitmap Cache Parser les affiche à côté des tuiles normales, avec le marqueur Reste d'emplacement. Un reste est un fragment d'une image plus ancienne, pas une tuile complète : précisez-le quand vous en citez un dans un rapport.
Le format RDP 8 Cache*.bin
Les versions plus récentes du client écrivent Cache0000.bin, Cache0001.bin, etc. La structure est plus simple.
En-tête de fichier
| Offset | Taille | Champ |
|---|---|---|
0x00 | 8 | Signature RDP8bmp\0 |
0x08 | 4 | Version (u32) |
Enregistrements de tuiles
Les tuiles se suivent sans interruption jusqu'à la fin du fichier :
| Offset dans l'enregistrement | Taille | Champ |
|---|---|---|
0x00 | 4 | key1 |
0x04 | 4 | key2 |
0x08 | 2 | width |
0x0A | 2 | height |
0x0C | width×height×4 | Pixels, B, G, R, X, lignes de haut en bas |
Pas de compression, pas de champ de longueur (la taille se déduit de la largeur et de la hauteur), pas de remplissage d'emplacement. Les enregistrements sont contigus : il n'y a donc pas de restes au sens décrit plus haut.
Ce qu'aucun des deux formats ne stocke
| Absent | Conséquence |
|---|---|
| Horodatages | Datez les sessions avec d'autres artefacts (artefacts du poste source) |
| Coordonnées à l'écran | Les écrans se reconstruisent à l'œil (reconstruction) |
| Identifiants de session ou de cible | Rattachez à une cible avec les journaux et le registre, pas avec le cache |
| Doublons | Les éléments identiques ne sont mis en cache qu'une fois |
Ce que le parseur affiche pour chaque tuile
Pour chaque tuile, le panneau de détail de RDP Bitmap Cache Parser indique la clé de cache, la largeur et la hauteur, la profondeur de couleur, la compression et l'offset dans le fichier, pour que vous puissiez vérifier n'importe quelle tuile dans un éditeur hexadécimal ou la comparer à la sortie de bmc-tools. Voir le comparatif des parseurs de cache RDP pour les différences entre outils.
Questions fréquentes
Le format des fichiers du cache bitmap RDP est-il documenté par Microsoft ?
Non. La structure de bcache*.bmc et de Cache*.bin est connue grâce à la rétro-ingénierie, principalement celle de bmc-tools de l'ANSSI. Seuls les codecs bitmap utilisés dans les tuiles .bmc compressées sont documentés : le RLE entrelacé dans MS-RDPBCGR et, pour les tuiles 32 bits, le codec planar de RDP 6.0 dans MS-RDPEGDI.
Quelle différence entre bcache22.bmc et bcache24.bmc ?
La profondeur de pixel des emplacements : bcache22.bmc stocke 16 bits par pixel, bcache24.bmc 32 bits par pixel. bcache2.bmc stocke 8 bits par pixel.
Pourquoi certaines tuiles ont-elles de mauvaises couleurs ?
Le plus souvent, ce sont des tuiles 8 bits. La palette de la session n'est pas stockée dans le cache : les décodeurs se rabattent sur une palette Windows par défaut et les couleurs sont approximatives. Les formes et le texte restent en général lisibles.