Friday, June 6, 2008

New version of EnCase includes stand-alone utility to capture RAM

Guidance Software has released version 6.11 of EnCase this past week. For awhile now, EnCase has had the ability to collect the RAM for the local machine that it is running on, as well as a remote machine in the Enterprise version. This was all great, but for the folks who had the Forensic version, it did not offer any realistic use, since nobody was going to load EnCase on a target machine in order to dump RAM.

The new version of EnCase (v6.11) now includes a stand-alone RAM collection tool called 'winen.exe'. This tool is installed with the standard installation of EnCase and is placed in the EnCase home folder. This tool was designed to be deployed on a flash drive or other media to a target machine and then used to collect the RAM contents before the system is shutdown. The tool collects RAM and places the collected information into an .E01 file automatically, which can then later be loaded into EnCase when doing the analysis portion of the response.

There is a 32-bit version as well as a 64-bit version located in the EnCase directory. To use, you can copy the "winen.exe" file or "winen64.exe" file to a flash drive or removable HD and then invoke at a command prompt or double click on the Windows GUI (not recommended). The tool is a console application so if it is launched in the GUI, it will spawn a command shell and then close after it completes.

No command line options are required when you run it, but by supplying some, you can skip the need to enter some information. When run with no command line options, you will need to answer six questions:

Please enter a value for the option "EvidencePath":
Please enter a value for the option "EvidenceName":
Please enter a value for the option "CaseNumber":
Please enter a value for the option "Examiner":
Please enter a value for the option "EvidenceNumber":
Please enter a value for the option "Compress":

The first question is a little deceiving by the wording. You must supply the path AND filename of the .e01 file you want to create. In this example, I created a file named "memdump" (.E01 is automatically added) on the Z drive. The EvidenceName option is for the name of the object inside EnCase. Once it is loaded in EnCase it will appear with that name in the Tree Pane. The rest are self-explanatory. The Compress option takes one of three values, 0=none, 1=good, 2=best.

By running "winen.exe -h" you can get a list of command line switches that let you specify all of this at the command line, making it completely automated and non-interactive for use in batch files, etc. You can also use the '-f' option to specify a text config file with these options. An example config fie is included in the EnCase home directory.

Z:\>winen.exe -h
Usage: [Options]
-p : Evidence File Path
-m : Evidence Name (Max Size:50)
-c : Case Number (Max Size:64)
-e : Examiner Name (Max Size:64)
-r : Evidence Number (Max Size:64)
-d : Compression level (0=None, 1=Fast, 2=Best) (Default: 0) (min:0 max:2)
-a : A semicolon delimated list of Alternate paths
-n : Notes (Max Size:32768)
-s : Maximum file size in mb (Default: 640) (min:1 max:10485760)
-g : Error granularity (Sectors) (Default: 1) (min:1 max:1024)
-b : Block size (Sectors) (Default: 64) (min:1 max:1024)
-f : Path to configuration file
-t: Turns off hashing the evidence file (default: true)
-h: This help message

The end result is a '.E01" file that loads into EnCase:

As far as the footprint left on the target system, the "winen.exe" program creates a service named "winen_". This obviously means that you need to have administrator privileges on the target system in order to use this tool. The program also drops a driver file named 'winen_.sys', in the directory where the program is run. Notice there is already a 'winen_.sys file' included in the EnCase home directory that you can copy and use with the winen.exe program, or when run, the program will create a new one. Take note of this, because the 'winene.exe' program creates a Windows service, this means there are changes in the registry occurring. Here is a screenshot of the service entry in the registry after running the tool on the target system:

The *downside* is that this service entry remains after the tool is run and if it is run from local media (i.e. C drive) then this service starts every time the system is rebooted.

The *upside* of this tool as it appears to dump the contents of RAM for all versions of the Windows NT platform, i.e. Windows 2000, XP, 2003 & Vista! Currently, there are very limited number of tools that can do this and most are not free!

I have not seen any "official" technical specs or details on the tool's capabilities, but the preliminary tests I have done seem to be very promising as a very useful Incident Response tool, especially if you are already an EnCase v6 user, then you just obtained a simple tool that can collect RAM on all of today's modern Windows platforms at no extra cost!

Nice job Matt! ;)


Keydet89 Sunday, 15 June, 2008  

Anytime you interface with a live system, you're going to leave footprints or artifacts. There have been 'forensic' and incident response applications where the authors have espoused deleting these artifacts...however, the list is never complete. IMHO, if you must interact with a live system, leave the artifacts in order to assist in establishing a legit timeline.

I would be curious how winen compares to mdd. Not head-to-head, per se, but use winen to dump memory, then open that dump in EnCase and dump it out to HBGary's Responder, and compare that to a similar dump from mdd.

In a way, I find it surprising that GSI is segregating itself this of the things one *should* try to avoid is methods of collection that channelize the analyst into a single application for analysis. Sure, .EOx files can be opened and 'dumped' to dd-style format with FTK Imager, but that requires additional steps. The ability to verify information by using different tools/procedures is important in this field.

Also, it's kind of interesting that winen collects physical memory in a format that even HBGary's Responder tool doesn't recognize.

Note: this isn't a comment to bash EnCase or anyone...just pointing out some issues that should be considered when deciding to use these tools.


seartho Tuesday, 31 May, 2011  
This comment has been removed by a blog administrator.

Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles