bcache24.bmc y Cache0000.bin: formato de la caché RDP
Estructura byte a byte de la caché RDP: ranuras bcache*.bmc y cabeceras de 20 bytes, RLE entrelazado, profundidades, restos de ranura y Cache*.bin RDP8bmp.
Resumen. Los archivos heredados bcache*.bmc no tienen cabecera de archivo: son una sucesión de ranuras de tamaño fijo, cada una con una cabecera de 20 bytes (key1, key2, ancho, alto, longitud de datos, flags) seguida de un área de 64×64 píxeles a 1, 2 o 4 bytes por píxel. Las filas van de abajo arriba; el flag 0x08 marca un mosaico comprimido con RLE entrelazado de RDP. Cache0000.bin y sus hermanos empiezan por RDP8bmp\0 y una versión, y después contienen mosaicos de 32 bits sin comprimir, uno tras otro, cada uno detrás de una cabecera de 12 bytes, con las filas de arriba abajo. Microsoft no documenta ninguna de las dos estructuras de archivo: lo que sigue procede de ingeniería inversa, principalmente de bmc-tools de la ANSSI, y es lo que implementa RDP Bitmap Cache Parser.
Si el artefacto es nuevo para usted, lea primero la guía de análisis forense de la caché de mapas de bits RDP.
Dos formatos, una carpeta
| BMC heredado | Caché persistente RDP 8 | |
|---|---|---|
| Archivos | bcache2.bmc, bcache22.bmc, bcache24.bmc (bmc-tools menciona también bcache23.bmc) | Cache0000.bin, Cache0001.bin, ... |
| Lo escribe | Clientes antiguos; aún puede encontrarse en sistemas actuales | Versiones más recientes del cliente |
| Cabecera de archivo | Ninguna | RDP8bmp\0 + versión u32 |
| Registro de mosaico | Cabecera de 20 bytes + área de ranura fija de 64×64 | Cabecera de 12 bytes + exactamente ancho×alto×4 bytes |
| Profundidad de color | 8, 16 o 32 bpp según el archivo | 32 bpp (B, G, R, X) |
| Orden de filas | De abajo arriba | De arriba abajo |
| Compresión | Algunos mosaicos, RLE entrelazado | Ninguna |
| Posibles restos | Sí | No (los registros están empaquetados) |
Entradas del glosario: bcache*.bmc, Cache*.bin.
El formato heredado bcache*.bmc
Nombre de archivo y profundidad de color
El número del nombre indica la profundidad de la ranura:
| Archivo | Bits por píxel | Bytes por píxel | Tamaño de ranura (20 + 64×64×Bpp) |
|---|---|---|---|
bcache2.bmc | 8 | 1 | 4.116 bytes |
bcache22.bmc | 16 | 2 | 8.212 bytes |
bcache24.bmc | 32 | 4 | 16.404 bytes |
Los tamaños de ranura son simple aritmética a partir de la estructura siguiente, no valores documentados adicionales. bmc-tools menciona bcache23.bmc; aquí no lo describimos más.
Estructura de la ranura
No hay cabecera de archivo. El archivo es una serie de ranuras, y cada ranura empieza con una cabecera de 20 bytes (0x14), en little-endian:
| Desplazamiento | Tamaño | Campo | Significado |
|---|---|---|---|
0x00 | 4 | key1 | Primera mitad de la clave de caché |
0x04 | 4 | key2 | Segunda mitad de la clave de caché |
0x08 | 2 | width | Ancho del mosaico en píxeles |
0x0A | 2 | height | Alto del mosaico en píxeles |
0x0C | 4 | length | Longitud de los datos del mosaico que siguen |
0x10 | 4 | flags | Bit 0x08: comprimido |
Tras la cabecera viene el área de la ranura, de 64×64×bytes por píxel, sea cual sea el tamaño real del mosaico. Un mosaico de 64×64 la llena; un mosaico de 16×64 en el borde de la pantalla solo usa una parte.
Los nombres de los campos son descriptivos, no oficiales. Lo importante es que key1 y key2 forman juntos la clave de 64 bits del mapa de bits.
Mosaicos sin comprimir
Cuando el flag 0x08 no está activo, los datos son píxeles en bruto. Los bytes por píxel son length ÷ (width × height). Las filas se guardan de abajo arriba, como en un BMP, así que el decodificador tiene que invertirlas.
Un detalle que conviene conocer al comparar herramientas: bmc-tools asume un paso de fila de 64 píxeles en la ranura. RDP Bitmap Cache Parser usa el ancho propio del mosaico como paso de fila en los mosaicos de menos de 64 píxeles de ancho. En esos mosaicos, las dos herramientas pueden producir imágenes distintas; si un mosaico estrecho aparece inclinado en una, pruebe con la otra.
Mosaicos comprimidos: RLE entrelazado
Cuando el flag 0x08 está activo (bmc-tools trata este bit como el flag de compresión; su significado se ha deducido, no está documentado para este archivo), los datos están comprimidos con el códec de mapas de bits RLE entrelazado de RDP. Ese códec sí está documentado, en la sección 2.2.9.1.1.3.1.2.4 de MS-RDPBCGR. Los mosaicos de 32 bits comprimidos también pueden usar el códec planar de RDP 6.0, documentado en MS-RDPEGDI; bmc-tools omite esos mosaicos, mientras que RDP Bitmap Cache Parser los decodifica.
El flujo es una secuencia de órdenes. Cada orden tiene una forma normal, una forma «lite» y, para las series largas, una forma «mega-mega». Las familias:
| Familia de órdenes | Qué codifica |
|---|---|
| Serie de fondo | Copia píxeles de la línea de barrido anterior (negro en la primera línea) |
| Serie de primer plano | Píxel de la línea anterior XOR un color de primer plano (el propio color en la primera línea) |
| Imagen FG/BG | Una máscara de bits que elige entre los dos casos anteriores |
| Serie de color | Un color repetido |
| Imagen de color | Píxeles literales |
| Serie tramada | Dos colores alternos |
| Blanco / negro | Un único píxel blanco o negro |
Como las series de fondo hacen referencia a la línea anterior, un solo byte corrupto puede emborronar el resto del mosaico. Un mosaico que el decodificador no puede descomprimir por completo se marca como «No decodificado» en la herramienta en lugar de rellenarse por aproximación.
Mosaicos de 8 bits y la paleta
La paleta de una sesión de 8 bits no se guarda en la caché. Los decodificadores, bmc-tools y el nuestro incluidos, usan una paleta de Windows por defecto, así que los colores son aproximados. El texto y las formas de las ventanas suelen seguir siendo legibles; no saque conclusiones de los colores exactos de un mosaico de 8 bits.
Restos de ranura
Las ranuras tienen un tamaño fijo y se reutilizan. Cuando se escribe un mosaico más pequeño en una ranura que antes contenía uno más grande, la parte no usada de la ranura puede conservar píxeles del mosaico anterior. Ese sobrante es un resto de ranura.
Los restos importan: pueden ser la única huella que queda de algo que estuvo antes en pantalla. En el ejemplo ficticio incluido en la herramienta, una ranura de bcache22.bmc todavía conserva la parte superior de un mosaico anterior: la barra de título de una ventana de editor con creds.txt, un archivo que se creó y después se borró en el equipo remoto.
bmc-tools exporta los restos con -o / --old. RDP Bitmap Cache Parser los muestra junto a los mosaicos normales, marcados como «Resto de ranura». Un resto es un fragmento de una imagen anterior, no un mosaico completo: indíquelo así cuando lo incluya en un informe.
El formato RDP 8 Cache*.bin
Las versiones más recientes del cliente escriben Cache0000.bin, Cache0001.bin, etc. La estructura es más sencilla.
Cabecera de archivo
| Desplazamiento | Tamaño | Campo |
|---|---|---|
0x00 | 8 | Firma RDP8bmp\0 |
0x08 | 4 | Versión (u32) |
Registros de mosaico
Los mosaicos se suceden uno tras otro hasta el final del archivo:
| Desplazamiento en el registro | Tamaño | Campo |
|---|---|---|
0x00 | 4 | key1 |
0x04 | 4 | key2 |
0x08 | 2 | width |
0x0A | 2 | height |
0x0C | width×height×4 | Píxeles, B, G, R, X, filas de arriba abajo |
Sin compresión, sin campo de longitud (el tamaño se deduce del ancho y el alto), sin relleno de ranura. Los registros están empaquetados, así que no hay restos en el sentido anterior.
Lo que ninguno de los dos formatos guarda
| Ausente | Consecuencia |
|---|---|
| Marcas de tiempo | Feche las sesiones con otros artefactos (artefactos del equipo de origen) |
| Coordenadas en pantalla | Las pantallas se reconstruyen a ojo (reconstrucción) |
| Identificadores de sesión o de destino | Atribuya a un destino con registros de eventos y registro de Windows, no con la caché |
| Duplicados | Las piezas idénticas se guardan una sola vez |
Lo que muestra el parser por mosaico
Para cada mosaico, el panel de detalle de RDP Bitmap Cache Parser indica la clave de caché, el ancho y el alto, la profundidad de color, la compresión y el desplazamiento en el archivo, para que pueda contrastar cualquier mosaico con un editor hexadecimal o con la salida de bmc-tools. Vea la comparativa de parsers de caché RDP para conocer las diferencias entre herramientas.
Preguntas frecuentes
¿Documenta Microsoft el formato de archivo de la caché de mapas de bits RDP?
No. La estructura de los archivos bcache*.bmc y Cache*.bin se conoce por ingeniería inversa, sobre todo gracias a bmc-tools de la ANSSI. Solo están documentados los códecs de mapas de bits de los mosaicos .bmc comprimidos: el RLE entrelazado, en MS-RDPBCGR, y, para los mosaicos de 32 bits, el códec planar de RDP 6.0, en MS-RDPEGDI.
¿Qué diferencia hay entre bcache22.bmc y bcache24.bmc?
La profundidad de color de las ranuras: bcache22.bmc guarda 16 bits por píxel y bcache24.bmc, 32 bits por píxel. bcache2.bmc guarda 8 bits por píxel.
¿Por qué algunos mosaicos tienen colores incorrectos?
Casi siempre son mosaicos de 8 bits. La paleta de la sesión no se guarda en la caché, así que los decodificadores recurren a una paleta de Windows por defecto y los colores son aproximados. Las formas y el texto suelen seguir siendo legibles.