Manual review of data structures

#dfirsummit has been generous this year in that they’ve provided a free live stream of the 2 days of presentations. This quick post was prompted from listening to Lee “Gervais” Whitfield, and his discussion of where to look to disprove the ‘bios clock changed’ conspiracy when it comes to disputing the evidence on your hard drive.

He indicated several locations that exhibit temporal anomalies should the clock in fact get changed. For example, thumbs.db (thumbnail databases in folders with images) stores thumbnail data sequentially – changes in the timestamps of those thumbnails may indicate time change.

He was asked, what are the Top3 places to look for for evidence of clock changes, and as #1 he mentioned Event Logs. But I don’t think for the reason why it is #1. He mentioned one event for XP and a couple of events for Vista/7 that show the clock being changed that get recorded in the event log. This is good of course, but I believe the real deal with event logs is just as with thumbs.db. Data is written to the event log sequentially – it is not ordered chronologically.

Talking Windows OS and NTFS.

Again: event logs are written to the NTFS file system, and then individual events appended to the log. If the clock changes, new events are appended to the log with these new timestamps. This is where reliance on tools such as Encase/FTK to perl scripts, to Event Log explorers, even log2timeline, that may auto-sort events for us chronologically for presentation, or at the least, our first step is to sort output chronologically. If we manually inspect the contents of the event log file with a hex editor (i.e. a raw view), and do some decoding ourselves, we can see the jump in time/anomaly clearly.

Of course what is ‘clear’ is subjective – but this is a good example of where manual review of data structures may in fact save the day rather than relying on our tools. Manual review of data sources may only be appropriate for certain scenarios, and I’m not recommending it as a daily approach; but it is something to be mindful of when trying to prove a point.

Stability Index and Reliability

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).

OutsideIn Part4

Just a quick addendum.

I ran the OutsideIn-PDF tool to produce PDFs (for further combination in to a PDF portfolio) and ran in to filename problems with my batch files – when those filenames have spaces in them.

Here is some VB script that can be executed from the current folder that replaces all spaces with underscores. (Shamelessly ripped from some place in Google Cache land).

dim objFileSys, file, folderName, folderObj, fileColl, objRegEx, newFile

set objFileSys = CreateObject("Scripting.FileSystemObject")
folderName = "."

set folderObj = objFileSys.GetFolder(folderName)
set fileColl = folderObj.Files
set objRegEx = new RegExp

objRegEx.Pattern = " "
objRegEx.Global = true 

for each objFile in fileColl
 newFile = objRegEx.Replace(objFile.Name, "_")
 objFileSys.MoveFile objFile, folderName & "\" & newFile
next

 

LNK Files and NTFS Anomaly

I periodically review LNK files and their timestamps either as a result of case work or because of some strangeness I observe through various experiments that I conduct. My reference for LNK file artifacts and behavior comes from the excellent paper by Harry Parsonage, the Meaning of LIFE.

My most recent encounter with LNK files came when I attempted to show that a file had been opened and ‘Saved As’ to  a new file.  The following artifacts do not show this, rather they show a surprising timestamp anomaly within NTFS.

Test Setup

1. 2gig thumbdrive formatted NTFS
2. LNK files were read from the Office\Recent folder on my Windows XP SP3 machine.

Test 1

Create test2test.xlsx	7:55pm
Double click to open and edit	7:56pm
Save	7:57pm
Close Excel	7:57pm

So at approximately 7:55pm I created a new spreadsheet on the thumbdrive called test2test.xlsx, opened it, added some text, and saved the file, closing Excel at 7:57pm.

The following table shows NTFS and LNK file timestamps.

NTFS Timestamps	Test2test.xlsx	Office\recent\test2test.xlsx.lnk
ACCESSED	19:57:30	19:56:26
CREATED	19:55:33	19:56:26
WRITTEN	19:57:30	19:56:26
MODIFIED	19:57:30	19:56:26
Internal Timestamps
ACCESSED		19:56:26
CREATED		19:55:33
WRITTEN		19:55:33

Pretty standard stuff here. The create date of the LNK file is when I first opened the spreadsheet for editing. The internal accessed timestamp is different from the accessed timestamp of test2test.xlsx. This threw me for a while, but it actually makes sense when you examine how Excel operates. Excel creates a temp file for editing (i.e. ~$test2test.xlsx). When excel closes, the last accessed timestamp of test2test.xlsx is the time when the editing was finished – why? because Excel overwrites test2test.xlsx with the contents of ~$test2test.xlsx. However the internal timestamps in the LNK file do not show this, they show when the actual file test2test.xlsx was opened. The cool thing here is that you can show how long an editing session was.

The anomalous part comes up now….

Test 2

Double click to open	8:15pm
Save as test3test.xlsx	8:15pm
Close excel	8:15pm

I opened the file test2test.xlsx, and did a Save As test3test.xlsx.

The following table shows the NTFS and LNK timestamps:

NTFS Timestamps	Test2test.xlsx	Office\recent\test2test.xlsx.lnk	Test3test.xlsx	Office\Recent\test3test.xlsx.lnk
ACCESSED	20:02:57	20:15:04	20:15:27	20:15:27
CREATED	19:55:33	19:56:26	20:15:26	20:15:27
WRITTEN	19:57:30	20:15:04	20:15:27	20:15:27
MODIFIED	20:14:48	20:15:04	20:15:27	20:15:27
Internal Timestamps
ACCESSED		20:15:04		20:15:27
CREATED		19:55:33		20:15:26
WRITTEN		19:57:30		20:15:27

There was no activity between the first set of captured timestamps and the second. The anomalous part is the Last Accessed timestamp for test2test.xlsx. Why 20:02? No idea…. The internal timestamps of the test2test.xlsx.lnk file are supposed to be the timestamps of test2test.xlsx at the time the file was opened. But when I finished my testing and started to capture timestamps for this table, the last accessed time had changed. Odd.