Crossing Streams
I'm not an anti-Linux, Windows-only guy. I'm just a guy who's used Windows, done vulnerability assessments of Windows systems, and been asked to do IR and forensic analysis of Windows systems for a long time. I also like looking in other places for something I can use to make my job easier, progress more smoothly, and allow me to perform a more comprehensive analysis of Windows systems. Because you can find SQLite databases on Windows systems (usually associated with a third-party application, such as Firefox or Chrome, or found in iDevice backups), I like to see what's out there in the DFIR community with respect to this database structure, and the LinuxSleuthing blog has been both generous and valuable in that regard.
The blog as a whole, and this post specifically, contains a lot of great info, but this time, it wasn't the technical info within the post that caught my attention...it was something of a crossing of the streams. What I mean by that is that I saw a couple of statements in the post that reminded me of things I'd said in my own blog, and it was as if two different people, with different backgrounds, interests, etc., were following the same (or very similar) reasoning.
The first statement:
It is very common in SQLite databases for integers to represent a deeper meaning than their numeric value.
This sentence took me back to my post on understanding data structures. Much like many of the data structures on Windows systems, the SQLite table in question has a column that contains integers, which must be translated in order to be meaningful to the analyst. Either the analyst does this automatically, or a software tool, which provides a layer of abstraction over the raw data, does it for us. In this case, "4" refers to an "incoming" call...that's important because doing a text-based keyword search for "incoming" won't reveal anything directly pertinent to the table or column in question.
In the case of Windows systems, a 4 byte DWORD value might be an identifier, providing information regarding the type of something, or it might be a flag value, containing multiple settings AND'd together. Our tools tend to provide a layer of abstraction over the data, and many will translate the integers to their corresponding human-readable values. As such, it is important that we understand the data structure and it's constituent elements, rather than simply relying on tools to spit out the data for us, as this helps us better understand the context of the data that we're looking at.
Consider the DOSDate time stamps found embedded in some shell items...what do they represent, and where do they come from? Okay, we have something of an understanding of what they represent - the MAC times of the target resource (folder, file usually). If the file system in which the target resource resides is NTFS, we know that the values start as FILETIME objects with 100 nanosecond granularity, are truncated to the second, and then (per the publicly available MS API), the second value is multiplied by 2. So, an NTFS time value of "23:15:05.657" becomes "23:15:10", and we have a considerable loss of granularity. We also know that the embedded time stamps are a snapshot in time, and that the resources can be impacted by actions outside the purview of the shell items. For example, after a shell item ID list within an LNK file is created, files can be added to or deleted from one of the constituent folders, updating the last modification time. Finally, of what value is the last accessed time on Vista and above systems?
So, my (rather long winded) point is that when we see a date/time stamp labeled "last access time" in the output of a tool, do we really understand the context of that integer value?
Okay, on to the second statement...
If you thought use another tool and see what it says then go outside and drag your knuckles on the concrete for a bit.
This statement reminded me on my thoughts on what I refer to as the tool validation "myth-odology".
Consider another recent blog post regarding LNK file parsing tools; in that post, I described the issue I wanted to test for, and then after querying a forum for the tools folks currently used to parse these files, I ran several of them against some test data. In this case, my goal was to see which of the tools correctly parsed shell item ID lists within the LNK files. Given this goal, would you download a tool that does NOT parse/display the shell item ID list in an LNK file, and use it to validate the output of other tools?
Here's the issue...many of the tools recommended for parsing LNK files parse only the header and LinkInfo block, and not the shell item ID list. Some that do parse the shell item ID lists do not appear to do so correctly. The shell item data structures are not isolated to just LNK files, they're actually pretty pervasive on Windows systems, but I chose to start with LNK files as they've been around for a lot longer than other artifacts, and tools for parsing them might be more mature.
So, why the interest in shell item ID lists? Well, in most normal cases, the shell item ID lists might simply provide redundant information, replicating what's seen in the LinkInfo block. However, there are legitimate cases where Windows will create an LNK file for a device (smart phone, digital camera, etc.) that consists solely of a header and a shell item ID list, and does not contain a LinkInfo block. Not being able to accurately parse these LNK files can present an issue to IP theft (devices are great at storing files) and illicit images cases (might mean the difference between possession and production). Also, there is malware out there that uses specially-crafted LNK files (i.e., "target.lnk") as a propagation mechanism.
Given all this, if someone wants to use the output of a tool that does not parse the shell item ID list of an LNK file to validate the output of another tool, I think the above imagery of "drag your knuckles" is appropriate. ;-) Just sayin'.