Skip to content

Cache0000.binbcache24.bmc

RDP Bitmap Cache Parser

See what the remote screen showed. Decode the RDP client's bitmap cache — legacy bcache*.bmc and Cache0000.bin — browse every tile, lay them out like bmc-tools and rebuild screens by hand. Parsed in your browser with WebAssembly: nothing is uploaded.

Drop RDP cache files here

Cache0000.bin, Cache0001.bin… and bcache2.bmc, bcache22.bmc, bcache24.bmc from Users\<name>\AppData\Local\Microsoft\Terminal Server Client\Cache\. Folders and ZIP triage collections (KAPE, Velociraptor) work as-is.

A synthetic cache drawn for a fictional intrusion — no real data. Tip: open Collage and set 7 tiles per row.

100% client-side: files are decoded by WebAssembly in your browser and never uploaded.

How to get your data

Full acquisition guide

The cache sits on the machine the Remote Desktop client ran on — the source of the connection — in each user's profile. Copy the whole Cache folder for every account, then drop the result here.

  1. Copy each profile's Terminal Server Client\Cache folder
  2. Drop the folder or ZIP here
  3. Decoded in your browser, never uploaded

Close any open Remote Desktop Connection window first (files in use cannot be copied). Then paste into Windows PowerShell run as administrator: it copies every account's Cache folder, keeping the Users\<name>\ layout.

PowerShell · Admin
Get-ChildItem C:\Users -Directory | ForEach-Object {
  $rel = "Users\$($_.Name)\AppData\Local\Microsoft\Terminal Server Client\Cache"
  if (Test-Path "C:\$rel") { robocopy "C:\$rel" "C:\triage\$rel" /E /B /R:0 /W:0 /NP /NDL /NFL | Out-Null }
}

Result: C:\triage\Users\<name>\AppData\Local\Microsoft\Terminal Server Client\Cache\ with the .bin and .bmc files. Drop the C:\triage\Users folder here (drag it, or use Choose a folder).

Analysing on another machine? Pack it into one ZIP with the tar.exe built into Windows 10 1803 and later:

PowerShell / cmd
tar -a -c -f C:\triage\rdpcache.zip -C C:\triage Users

Gotchas

  • A file in use by an open Remote Desktop session may fail to copy: close the session, or use KAPE or a disk image.
  • Copying changes no evidence, but the files' own timestamps are your only clue to when sessions happened: record them (or collect $MFT) before anything else.
  • Persistent bitmap caching can be turned off in the client or an .rdp file: an empty or missing folder does not prove there was no RDP use.

What is the RDP bitmap cache?

To avoid downloading the same screen pieces again, the Remote Desktop client (mstsc.exe) keeps a persistent cache of small bitmaps — usually 64×64-pixel tiles — sent by the remote machine. The files stay in the profile of the user who ran the client.

Put back together, the tiles show fragments of what that user saw on the remote screen: consoles and the commands in them, folder windows, tools, documents. For an investigator that is rare, visual evidence of lateral movement, collected on the source machine.

Where it is stored

  • C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\ on the machine the connection was made from.
  • Cache0000.bin, Cache0001.bin…: newer format, a "RDP8bmp" header then uncompressed 32-bit tiles.
  • bcache2.bmc, bcache22.bmc, bcache24.bmc: legacy format, fixed 64×64 slots at 8, 16 or 32 bits per pixel, tiles often compressed with the RDP interleaved RLE codec.

Why it matters in an investigation

  • Shows what an attacker or administrator actually looked at on the remote host — even when that host was wiped or never imaged.
  • Console tiles can reveal commands, paths and tool names; explorer tiles reveal folder and file names.
  • Its presence alone proves the account used the Remote Desktop client on this machine; correlate with the client event log and registry to name the target and date the sessions.
  • Legacy slots can keep fragments of older tiles (slot remnants).

Limitations

  • Tiles have no timestamps and no screen position: the order is cache order, and identical tiles are stored once.
  • Only what the server sent as bitmaps is cached; some sessions leave few usable tiles, and the cache is capped in size and recycled.
  • 8-bit legacy tiles lack their palette, so colours are approximate. There is no OCR: tiles must be read by a human.
  • Heuristic hints (console-like, text-like) can miss tiles or flag harmless ones.

How to get the files

  • Collect the whole Cache folder of every profile with KAPE (RDPCache target), Velociraptor (Windows.Triage.Targets, RDPCache) or from a disk image.
  • Record the files' timestamps: they are the main clue to when sessions happened.
  • Keep the Users\<name>\ folder structure so each cache is attributed to its account.

FAQ

Are my cache files uploaded anywhere?

No. The decoder is Rust compiled to WebAssembly and runs in a Web Worker in your browser. There is no upload endpoint; tiles, collages and exports are built locally.

How is this different from bmc-tools?

It has its own decoder, written independently from Microsoft's specifications and validated against bmc-tools, then adds what is hard on the command line: a searchable gallery, collage settings you can change instantly, a drag-and-drop reconstruction canvas, triage hints and exports (PNG, BMP with bmc-tools names, CSV, JSON). bmc-tools remains the reference to cross-check important findings.

Can it tell me when a tile was displayed?

No — the cache stores no time per tile, and this tool does not invent one. Date the sessions with the cache files' timestamps, the RDPClient/Operational event log (event 1024) and the Terminal Server Client registry keys.

Which machine holds the cache?

The client: the machine where Remote Desktop Connection ran, in the profile of the user who launched it. It shows the remote screen, so an attacker's pivot from host A to host B leaves B's screen fragments on A.

Why do my collage rows not line up?

Tiles are stored in the order they were cached, identical tiles only once, and edge tiles are smaller. Try other widths, then finish by hand in the Reconstruct view.

About the decoder

The decoder is an independent Rust implementation written from Microsoft's open specifications ([MS-RDPBCGR] for Interleaved RLE, [MS-RDPEGDI] for the RDP 6.0 planar codec) and public research such as the CERT-FR bulletin CERTFR-2016-ACT-017. ANSSI's bmc-tools (github.com/ANSSI-FR/bmc-tools), the reference tool for this artifact, was used to validate the output tile by tile; none of its code is used. Documented differences: tiles narrower than 64 px keep their real width, decompressed 8 and 32 bpp tiles keep their real colour depth, RDP 6.0 planar tiles are decoded, and damaged files are decoded as far as possible. Compare with bmc-tools on important cases.

Step-by-step: load bcache*.bmc and Cache*.bin files into a free in-browser parser, triage tiles, build a collage, rebuild a screen and export the evidence.
Which artifacts on the RDP source host show where a user connected and when, and how to use them to date and attribute what the bitmap cache shows.
Why an RDP cache collage lines up in places and drifts in others, how to pick the collage width, and how to rebuild a screen tile by tile on a canvas.