You are here: 42 Resources Blog tags Enscript

42 LLC

SANS

The Answer

Forensics, Security, Law

Tag >> Enscript
Jul 06
2010

Exporting BAG data + updated script

Posted by Yogesh Khatri in Shell BagsForensicsEnscript

Yogesh Khatri

A few people have complained to me about not being able to export data from the BAG Parser script. When exporting the parsed out information, it only outputs an empty tab-delimited file with column titles but no data.

This is not a bug with the script. The "Export" button on the script exports all leaf nodes but not folder nodes shown in the tree. This is a generic dialog that I use in all my scripts and its designed to be that way. However, the BAG data is mostly folders and hence the problem with exporting it.

Solution

Here's what you need to do to get the FULL output.

1. Use the "Export Selective" button.

2. On the dialog that pops up, select "Include Folders", choose all fields you want to export (all are selected by default) and hit OK.

Script Update

The script has been updated to include the above information in the "About" dialog.

Also, a bug has been fixed which caused some output to show up as garbage data (invalid Unicode).

Download here

May 26
2010

CEIC 2010 scripts

Posted by Yogesh Khatri in ForensicsEnscriptCEIC

Yogesh Khatri

 

Today we release several scripts and utilities for forensic analysis at CEIC 2010. This is some of the research we have been doing over the last year. Download links below. (You will need to log in to download the files. Registration is of course free.)

Apple iPhone Backup Extractor

Extract files into their proper folder structure from an iPhone backup

Download

Bag Parser

An update to the bag parser already posted here

Download

CSC Parser

Rebuilds XP Client side cache (CSC) from an XP machine and exports files as native or into a Logical Evidence File

Download

Google Desktop Search Metadata Extractor

Extracts information about files stored in Google desktop search's index

Download

Google Desktop Index Data Extractor

Extracts files stored in Google desktop search's index

Download

Windows Search Index Data Extractor

Extract textual data and metadata from the index database of Windows Search

Download

INDX Extractor

Finds deleted files (and their metadata) by reconstructing deleted INDX buffer records in NTFS volumes

Download

IPD Extractor

Extracts data from blackberry backup files, aka IPD files

Download

Webmail Extractor

Extracts mail listings from web pages, memory, page files or unallocated space for email for Gmail, Yahoo mail and Live mail (hotmail)

Download

 

Oct 07
2009

Shell BAG Format Analysis

Posted by Yogesh Khatri in WindowsShell BagsForensicsEnscriptartifacts

Yogesh Khatri
Windows uses the Shell BAG data to arrange folders and files in Explorer views, as well as to monitor recently used and frequently used applications in the Start-Menu among other things. Forensic experts use it to find traces of deleted file/folders with associated MAC times and file paths. It even tracks network paths and paths on external thumb drives that were once plugged into the machine.
When I started this research, I didn’t know of any product nor any freeware or documentation that explains the BAG format, so I decided to reverse engineer it myself. However since, I have learnt of a paper presented this year that talks about the BAG file and its usage to recreate user activity at the DFRWS conference. They have a tool called TraceHunter, available on request only, but no available documentation on the format. I haven’t seen the tool yet. Update: I have been informed by the folks at tracehunter that they will not be giving me a copy!
I have read on a blog that a once freeware tool to accomplish this was bought by Paraben and incorporated into their product ‘Registry Analyzer’ which is now called P2 Commander ($129).
About the BAG format
It is prevalent in all windows versions since XP and is used in following registry keys:
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\BagMRU
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StreamMRU
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
Vista and Windows 7 have these additional locations (updated)
  • HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags
  • HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
  • HKEY_CURRENT_USER\Software\Classes\Wow6432Node\Local Settings\Software\Microsoft\Windows\Shell\Bags
  • HKEY_CURRENT_USER\Software\Classes\Wow6432Node\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
My Research
Very little has been known about the technical specifications of the Shell BAG format. I present my research and an Encase script to parse NTUSER.DAT hives and extract the data. The source code is a mess right now and many things are hard-coded, so I have not made it available yet.
I have been able to understand the basic format, although there seems to be quite a few variations of how it’s used in the different registry keys and at different levels, ie, it varies depending on whether the BAG artifact is from a file or folder, regular file or ZIP file, etc.. Sometimes GUIDs are used (instead of filenames) for well known items like Control Panel as well as application created shortcuts.
Structure Format
struct BagFile {
USHORT BagSize; // Length of BAG structure
USHORT flags;
DWORD size;
USHORT ModifiedDOSDATE; //Modified Date GMT
USHORT ModifiedDOSTIME; //Modified Time GMT
USHORT FlagUnknown;
char  name[]; // (DOS short filename)
//extra byte here sometimes to align to even byte boundary
UnicodeBagData UnicodeData;
};
struct UnicodeBagData
{
USHORT LengthOfUnicodeStructure;
USHORT Short1; // 0x0003 for XP, 0x0008 for win7
USHORT Short2; // 0x0004
USHORT Short3; // 0xBEEF
USHORT CreatedDOSDATE; // Created Date GMT
USHORT CreatedDOSTIME; // Created Time GMT
USHORT AccessedDOSDATE; // Accessed Date GMT
USHORT AccessedDOSTIME; // Accessed Time GMT
DWORD Unknown; // usually xp = 0x14, win7 = 0x2A
// Vista and Windows 7 Extra Fields (22 bytes total)
DWORD  MftFileId;
USHORT Unknown1;
USHORT MftSequence;
DWORD  Unknown2;
DWORD  Unknown3;
DWORD  Unknown4;
USHORT Unknown5;
// END Vista extra fields
wchar name; // Unicode Filename
USHORT Unknown6;
};
Although this is the basic format, there are several variations depending on flag values.  The elements are likely contained in more structures nested within, hence the variations.
In the StreamMRU values, many such BAG structures are chunked together into one reg value, which represents the full file path.  For example, if a folder path is “C:\Program Files\Microsoft\Office”,  the registry value will have the following data
[BagFile for C:] + [BagFile for Program Files] + [BagFile for Microsoft] + [BagFile for Office]
All will be appended into the same reg value.
Files vs. Folders
Since BAG data is mostly used by Explorer to remember view settings for each folder, we only find BAG entries for Folder data under ‘Software\Microsoft\Windows\Shell\BagMRU’. Each folder under that key has a NodeSlot value which represents the unique folder number for its settings which are stored at ‘Software\Microsoft\Windows\Shell\Bag’.
The keys under this key store both file and folder metadata. Any time you move an icon in explorer, its new position in that folder is tracked here. For each NodeSlot value in BagMRU, there is a folder with that number as name. Not all views are tracked, so you will see some empty folders under this key and some with many values. One of these values will look like “ItemPos 1024x768(1)” or whatever your screen resolution is at the time of the event. There can be multiple of these items for multiple monitors, change in screen resolution, etc.. The ItemPosxxx key consists of many BAG structures appended together. Unlike StreamMRU, these don’t represent a file path, they are simply metadata for all the files/folders in that particular folder that it represents.
BAG Data Organization
The data is organised exactly as it appears in Windows Explorer, with the desktop being the root folder of everything.
The paths inside BAG files will have many redundant entries pointing to the same object in a different view depending on whether you browsed to the 'desktop' folder from C:\Documents and settings\... or directly accessed it from the Desktop, or from My Computer\Shared Documents\.. and so on.
Example: Redundant paths for an XP machine
Desktop\My Computer\C:\Documents and Settings\ProfileName\My Documents\..
Desktop\My Documents\..
Desktop\ProfileName's Documents\..
Desktop\ProfileName\My Documents\..
Script
This script (download link below) parses the data from an image or an NTUSER.DAT file. It tries to remove all redundant paths (removing duplicates), althought sometimes you would want that (dates/times on the duplicate entries may be different).
Ideally, you want to run this against a full disk image (just because it tries to resolve ProfileName if not found in registry hive), but it will parse out individual NTUSER.DAT files also. It will process profile hives stored under System Volume Information (System Restore) also! It has been mostly tested on XP but has been tweaked to run on Vista and Windows 7.
Update: There appear to have been quite a few additions to the format with Windows Vista and 7. Also a new location for these entries:
C:\Users\ProfileName\AppData\Local\Microsoft\Windows\UsrClass.dat
The additional paths are noted in section above in "About the Bag format".
Update (May 26 2010): New version of script available. Download here
Jun 18
2009

GMail Mailbox List Parser

Posted by Chris Pavan in gmailForensicsEnscriptartifacts

Chris Pavan
As a part of a case I was working on I needed to parse all of the GMail artifacts on several different hard drives. If you use GMail you are used to the preview you get when you view your Inbox. That preview (which is a JavaScript) is the only thing that actually gets left behind by Google, but it has some interesting artifacts in it.

Here is what you will typically find in a GMail mailbox listing:

• From - Who sent the message
• Subject - Subject of the message
• Preview - Snippet of the email message
• Attachments - Listing of the attachments with the message
• Short Date - Time if being viewed on the same day, month and day otherwise
• Long Date - Full date and time of when the message was sent
• Number of conversations - Count of messages that are a part of that thread

I wanted to search the entire drive for this artifact and parse the information so I asked Yogesh to create an EnScript for me. The script will only work properly in EnCase 6.12+. DOWNLOAD HERE

Make sure you have all of the items you want to search and parse blue checked (i.e. blue check everything to search the whole drive) and then run the script. Don't worry if the status bar hasn't moved, that is due to us not having time to code it. Once the script is done searching a dialog window will popup with the listing of the entries found. This view is similar to the table pane and if you blue check everything in this view, then right-click and choose Export, you can dump the list to a tab delimited file.

This is in Beta at the moment so if you find any bugs please let us know.

 

****Yogesh has updated the script to include Yahoo! mail and is working on some others. The new download works 6.14+  DOWNLOAD HERE.

Apr 05
2009

The Enscript Command line, New Possibilities

Posted by Yogesh Khatri in ForensicsEvidence VerificationEnscriptCommandLineCOM

Yogesh Khatri
As encase and E01 files have become the standard in digital forensics, I have been using the Enscript language built within encase to automate my tasks. It has become the language of choice for many reasons, it has a rich library of functions that can create dialogs for UIs, perform direct registry access without mounting (except user hives), read/write files and automate manual encase tasks like searching, filtering, etc. But the most compelling reason to use enscript is that I don't have to copy/unerase files from encase before working on them.

However, there are certain drawbacks. I wish to automate my tasks to a level where I shouldn't have to see encase at all. :) This is supported half way right now, an enscript can be launched from the command line with the -r switch to encase. But unlike regular programs, no parameters for the script can be specified on the command line, as the script cannot access Encase's command line. And that's a big show stopper. :(

The solution I came up with was to create a COM DLL that an enscript could load and one of the functions exposed in the DLL's interface would be the command line. Because the DLL is loaded from the Encase process (by the script), it can access Encase's command line. The DLL, enscript and batch file (for registering it with windows) can be downloaded below. Scroll to the end of article for link.

Usage:
1. The DLL must be registered with windows. To register the DLL, place it somewhere where it won't get moved or deleted like the windows folder.
2. Copy the batch file provided to the same location and execute it, this will register the DLL. Now it's ready for use.
3. Run the enscript in encase.

This now opens up a world of possibilities. We can now have encase launch, start an enscript, load an evidence file, process it, dump out results and quit all from a single command line statement. I can now create a batch file or even an item on the explorer right-click menu which processes my evidence files! The only thing missing is the ability to write back out to StdOut (Console). Because encase is a windows application, it does not attach to a console. :(

As a demo, I created a couple of scripts and integrated them into shell right-click menu items.
Script 1: Get Profile Info.Enscript
This can be run on a single E01 or L01 file.
This performs the following actions:
1. Load the specified E01/L01 file into encase.
2. Recurse through the entries in this file and find all windows profile names.
3. Create output file in the same folder as evidence file.
4. Write all profile information to this output file.
5. Close encase when done. (" -x" command line switch)

Script 2: Verify Evidence File.Enscript
This can be run on a single file or folder containing E01 files and can be either recursive or non-recursive. You can point it to the root of a drive and have it verify all files on that drive and get a single report for it. Similar to the "Get Profile Info" script, the output is stored into a file in the same folder as E01 file (if file is selected) or in the root folder selected.

Registering the Shell Handlers:
This is done by inserting a few keys into the registry. The zip files provided have registry scripts to do this automatically. Before running it, you will have to edit it with notepad to change the path of the script as well as the encase path to wherever they exist on your system. (You need double backslashes (\\) in the path in the .reg file only, not if you edit the registry directly. The same goes for the encase path. Also double-quotes have backslash pre-fixed to them. )

 Download files here:

Command Line DLL.zip
Get Profile Info.zip
Verify Evidence File.zip

42 LLC | 2596 Mission St, Suite 203, San Marino, CA 91108 | info@42llc.net | +1 626.698.1189