Plenty has been said about the “did they burn data to CD/DVD” question for Windows XP – but a recent case required me to answer the same question but this time for Windows 7. So has anything changed? Is it easier, harder? Well let’s find out.
Windows 7 comes with built in support for burning CD’s and DVD’s. A tool called Windows DVD Maker is provided to end-users as part of the Windows 7 operating system. This guide highlights artifacts that indicate if/when a blank CD/DVD was inserted in to the drive, and also how to determine what was burned to that media.
The Event Log
Windows 7 records information in 40+ event logs, not just the original big three (System, Application and Security). Several tests of burning data to DVD show that with under my current environment’s build and GPO configuration, the only event that gets written to a log is:
- Event ID 133. Source "cdrom"
And this gets written to the System Event Log only. While there is no supporting data for this event at EventID.net or in the Microsoft Knowledge Base, testing has shown that this event occurs when the burn button is clicked in Windows Explorer. Simply adding non-blank discs does not trigger this event.
The description, "locked for exclusive access" shows that the ‘burn’ process has actually started.
The Registry
The following key:
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\StagingInfo
contains a KvP that resembles this:
- Volume{77add596-7a9e-11e1-9114-806e6f6e6963}
The value "StagingPath" is significant. It shows the folder on the volume that is used to ‘stage’ files prior to committing them to the disc.
Once we have a file on an NTFS volume to look at, we can resort to standard file system forensics to figure out what, if anything, existed in this folder. (Remember, even folders are files to NTFS)
The Forensics
Deleted Files
When parsing an NTFS volume using Encase, the tool automatically assigns all deleted files, with intact MFT records, to the appropriate parent folder.
In other words, when you navigate to this folder using Encase, you may see deleted files in that folder. If they are in the clear, then you got very lucky and found a burning session in progress. Any file present in this folder, clear or deleted, is/was staged there as part of a burning session.
INDX Data
Remember, every folder in NTFS is a file. What does the "file" for the "\burn" folder contain? It contains a binary record structure that the Windows OS uses to display the contents of that folder called an INDX record. Here’s a sample:
The OS maintains the contents of this file on a real-time basis: as files are added to the folder, the content of this INDX is updated. As files are removed, the contents of this INDX are updated. Even though the folder is currently empty, it looks like there is some ‘leftover’ data in this file. Encase can parse this out for you using an enscript under Examples->Index Buffer Reader. Here’s a partial screenshot of what the output can look like:
The output shows that a file was present in this folder (you have a filename) and corresponding timestamps for that file show you when this occurred. It also comes with size information and MFT record information.
MFT Records – $LogFile
What is the $Logfile? It contains information used by NTFS for faster recoverability. The log file is used by Windows Server 2003 to restore metadata consistency to NTFS after a system failure. The size of the log file depends on the size of the volume, but you can increase the size of the log file by using the Chkdsk command. Source Microsoft KB Article (The Logfile is of course used in more than just Server 2003).
This file contains several useful artifacts, but the one we want are the MFT records. Encase has an enscript to parse this file, it’s under Case Processor.
Once parsed, your case will contain a series of bookmarks (sometimes 100s of the things), one bookmark for each MFT record found in the $LogFile. What do we want to look for in these bookmarks?
MFT records contains lots of useful information, but the piece we are looking for is called the "Parent MFT Record #". This associates a file with a particular parent folder, and that is basically how things are kept organized. So let’s find the MFT record for the "\Burn" folder.
The MFT record # for the Burn folder is 75485. Note make sure you select the right folder. You want the MFT record for that second ‘burn’ folder, not the first.
So, make your own Condition under the Bookmarks view called "Comment contains" that finds any comment that contains the parent MFT record #, and ta-da, you now have a list of files that once existed in that folder. Why? Because every MFT record also stores the MFT number of its parent folder.
MFT Records – The Journal File
What is this journal file? The USN Journal (Update Sequence Number Journal) is a system management feature that records changes to all files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume.[12] This journal can be enabled or disabled on non-system volumes[13] and is not enabled by default for a newly added drive. Source Wikipedia article on NTFS
This information is stored in a file called $USNJRNL, in the folder C:\$Extend. The files comes with two streams, and the one that contains the data we really want is:
Encase does not have a built-in enscript for parsing that file, but there are some scripts out there, along with standalone tools that can parse the Journal file. My favorite comes from TZWorks and is called Windows Journal Parser. Get it. Here is a sample output from this tool, already filtered to include files whose parent MFT ID matches that of the "\burn" folder:
The highlighted piece is the hex value for the parent MFT. Any entry that has this same parent MFT hex value once existed in this folder, therefore the data was burned, or staged for burning.
So that’s it? Any problems?
One thing I can think of, what if the user starts staging data in that folder but changes his mind and deletes it? Can I prove the actual burn took place? It looks like Event ID 133 occurs when the burn button is clicked, so if you can correlate this event to MFT records showing content in that folder, then it’s a solid conclusion to make. And I’m beginning to suspect that staging is not the write word to use. Continue reading.
If you look at the output of the USNJRNL parse, you’ll see that the file was copied and deleted all within the same second – I’d like to think that that indicates a successful burn. Some further testing is needed there – but it appears that staging doesn’t occur as I traditionally think of staging: as you select files and folders, place that data in the burn folder until you click Burn. That’s inefficient, instead it looks some sort of data structure is maintained in RAM to hold pointers to the data you wish to burn, and the actual commit to disk process involves taking each file, one at a time, and writing to the Burn folder, then to Disc, then deleting from the Burn folder.
I welcome any additional information you may have, especially if you have noticed different behavior or discrepancies in my write up.