While conducting an investigation in to removable media, on a Windows Vista 64bit computer, several searches had led me to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib09
A REG_MULTI_SZ value, called ‘Counter’, contains the following sample text:
Which lead me to the tool “Reliability and Performance Monitor”.
I have never looked at the “reliability monitor” before – but it contains something very interesting. A nice looking timeline of stuff.
Here’s a sample from the “Software (Un)Installs” section:
Sweet! Another 4n6 timeline artifact that may be immune to file system cleaners and uninstallers. How about those external devices?
Okay enough of that – what about deadbox analysis? On my test system, the files of interest are located in the path “C:\ProgramData\Microsoft\RAC\PublishedData”:
The ‘SWIT’ file contains the Software (Un)Install information, AFL is Application Failures, HFL is Hardware Failures, etc.
Let’s manually decode so that we can enscript them.
The following screenshot represents the record for Microsoft Silverlight, v4.0.51204.0, that indicates there was a successful Configuration Change made on January 8th, 2011 at 08:00:49 EST.
Here we go:
Bytes 0-15 represent a 128bit Windows SYSTEM timestamp. (See here)
typedef struct _SYSTEMTIME {
WORD wYear;
WORD wMonth;
WORD wDayOfWeek;
WORD wDay;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wMilliseconds;
} SYSTEMTIME,
*PSYSTEMTIME;
The cool thing here is that the time is available for analysis as opposed to just the date that is presented in the Perfmon MMC.
The next 128bytes contain a Unicode string representing the application. This byte stream is read until a NULL terminated string is found. In this case, “Microsoft Silverlight”. And to make sure you are paying attention, this field is reusable and can contain SLACK information! Woot.
The next 128bytes contain a Unicode string representing the version of the application. This byte stream is read until a NULL terminated string is found. In this case, “4.0.51204.0″. This field can also contain SLACK information.
The last 12 bytes contain the encoded events (I reversed these, couldn’t find a spec).
Four bytes at Offset 272 (the Purple bytes):
-
0×00 = Install
0×01 = Uninstall
0×02 = Ignore field
Four bytes at Offset 276 (the green bytes):
-
0×00 = Configuration change
0×01 = Application install
0×02 = System Update install
Four bytes at Offset 280 (the blue bytes):
-
0×00 = Failure
0×01 = Success
Writing a parsing tool for this is now cake.
Here’s an example from my own SWITable.DAT file that illustrates slack data (or what I’m calling slack data).
IzUYurlIIlnEpkWTWTLmKmxpEjwTR
