SANS Digital Forensics and Incident Response Blog

Using HELIX LIVE for Windows

by Craig Wright

The following is a simple introduction to starting Helix Live for Windows.

In the event that the CD autorun features is enabled, a Helix license Window should appear. If autorun is disabled, you can run Helix by double clicking on the helix.exe file on the CD. Newer versions of Helix are available, but the process is basically the same.

The Helix Live function is used to collect volatile data (evidence) and in cases where the system cannot be shutdown. Whenever you work on a live system, you need to ensure that you take care to minimize any changes to the system. Changes always occur on live systems. Just letting a system run creates change.

Figure 1 Helix Terms of Use Window


Now accept the Terms of Use. The default language that Helix will use via the drop-down box is English. French and German are also available. To use Helix, read the agreement and then press "I Agree" to continue. Once the terms have been accepted, the main screen will appear (See figure 1).

Figure 2 Helix Main Screen


After Helix's main screen appears, select any of the options by clicking on the associated icons (see Figure 2). The Helix Main screen doesn't behave as a standard window. Helix does not show up in the taskbar, and it is not possible to <ALT><TAB> to it. Helix places an icon in the system tray, which can be used to access the program (see Figure 3).

Figure 3 Helix Icon


By double-clicking or right-clicking on the icon and selecting "Restore", the main Helix window is brought to the front of the window. Other options on the right-click menu include Minimize and Exit.

The main screen provides access to three main examination options in Windows:

  • Preview System Information This option displays the basic information of the system. Information obtained includes the Operating system version, network information, owner information, and a summary of the drives on the system. There is also a second page that will show a list of running processes.
  • Acquire a "live" image of a Windows System using dd This enables the imaging of hard drives, floppy disks, or memory, and allows storing them on local removable media, or over a network.
  • Incident Response tools for Windows Systems There are a large number of tools (including the Windows Forensic Toolkit) that can be run directly from the CDROM. On clicking this icon, a small triangle will appear (see Figure 4).

Figure 4 Selecting Tools within Helix Live for Windows


Clicking on the triangle gives access to the other tools pages.

Explore all the following pages and try the tools:

  • Documents pertaining to Incident Response, Computer Forensics, Computer Security & Computer Crime This option accesses a number of reference documents in PDF format. These documents include a chain of custody form, preservation of digital evidence information, Forensic examination for digital evidence guide, and Linux forensics Guide for beginners. These documents are a great introduction in how to conduct a forensic examination.
  • Browse contents of the CD-ROM and Host OS This option takes the user to a file browser that provides basic information about the selected files. It displays the filename, (created, accessed and modified) dates, file attributes, CRC, MD5 and file size.
  • Scan for Pictures from a live system This option accesses a tool that can scan the system to find any suspect graphic images. Many different graphic formats are recognized, and these are displayed as thumbnails.
  • Investigative Notes This is a small notepad to make notes while working on the system

Helix's Quick Launch option provides access to a number of tools. Try them all and become familiar with their use (see Figure 5).

Figure 5 Helix's Quick Launch


It is important to note

The first time a file is selected on a live system; Helix will display the access date of the last access. If the same file is selected again, it will show the date and time of the preceding access. This is due to the nature of the Windows operating system. It cannot be prevented while in Live Mode (This is not an issue when booting into Linux Mode). When examining a live system remember that your actions may modify the system.This is due to the nature of live acquisitions. A live system will use a R/W (Read/Write) drive. This is necessary as the operating system has to write to the drive when it is being used. For this reason, you need to take care. Once all of the volatile data has been obtained and an image has been taken of the drive, the changes are less of an issue, but still should be minimized.

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he is helping to launch a Masters degree in digital forensics. He starts his second doctorate, a PhD on the quantification of information system risk at CSU in April this year.

19 Comments

Posted April 27, 2009 at 2:02 PM | Permalink | Reply

keydet89

The first time a file is selected on a live system; Helix will display the access date of the last access. If the same file is selected again, it will show the date and time of the preceding access. This is due to the nature of the Windows operating system.
How so? I can use both "dir /ta" and the Perl stat() function to get the last accessed time on a file without modifying it. Perhaps this is due to the manner in which Helix is accessing the file.

Posted April 27, 2009 at 4:20 PM | Permalink | Reply

craigswright

The difference is that you are not accessing the file. The access time of the perl command and the command shell will be updated.
What we are talking about is when a file is run (executed) or opened it is altered. Remember this is talking about a live system, not an image.
The "dir /ta" command does not list the file content. You can not see what a file contains. For instance, you may wish to check an image file to see if it is pornographic or something similar.
Many live systems can not be simply stopped and imaged. As you access and view files on a live system, you change the access times.
Even running perl from a CD changes access times on the system. The CD is mounted and dll's and exe's are run to access it.
Hence why you need to take care. Anything you do leaves a footprint and makes changes. Remember, you often have to validate an incident on a live system prior to imaging it. Imaging can take many hours and the system will change in this time.

Posted April 27, 2009 at 4:59 PM | Permalink | Reply

keydet89

What we are talking about is when a file is run (executed) or opened it is altered.
Sorry, that part wasn't clear. In the above post, the word "selected" was used, not "executed" or "run" or "launched".
Remember this is talking about a live system, not an image.
Right, I caught that from the post. I used "dir /ta" and Perl's stat() function on a live system, as well.
As you access and view files on a live system, you change the access times.
Sure, which is why one should collect file metadata prior to accessing/viewing files on a live system.
Anything you do leaves a footprint and makes changes.
You're absolutely right, and thanks for clarifying that''I hadn't thought of that.

Posted April 27, 2009 at 11:52 PM | Permalink | Reply

craigswright

Thanks for taking the time to ask a question. I think the clarifications will help other readers.

Posted April 28, 2009 at 8:18 AM | Permalink | Reply

forensicrob1

While it may be easier for a software developer to avoid changing the file access date in Linux, it is also possible in Windows. Our software, FI TOOLS, does not change the access date on files in a live system. I assume that more than half of the forensics and eDiscovery tools on the market avoid changing the date. That's part of being forensically sound.
Just reading metadata from the directory entry can change this date, so the file doen't necessarily need to be opened to change the date.

Posted April 28, 2009 at 5:24 PM | Permalink | Reply

craigswright

I have not used the File Investigator Engine or other FI tools products. So I can not say if this is the case or not.
There are ways of accessing files in Windows without altering timestamps, but most of these interfere with the operation of a live system.

Posted April 28, 2009 at 9:01 PM | Permalink | Reply

forensicrob1

Here's a method that doesn't interfere with the operation of a live system:
Step 1: Open the file.
Step 2: Read the access date.
Step 3: Perform your operation on the file.
Step 4: Reset the the file access date to the original value that you read.
Step 5: Close the file.
On Windows (and maybe DOS) the file's access date gets changed on the close command, not the open command. So, you have plenty of time to read the access date and write it back before you close the file. When you perform these steps, the file's access date never actually gets changed. Not even for a split second. It's as if the OS recognizes what you are doing and never bothers to change it. So, if you open the file with Read Only access, nothing gets written to the drive. We use this method in C. I don't know if it works in the .NET framework. If it doesn't, you can try to correct the access date after the file is closed. I don't see any reason that this would interfere with any other file on the live system. It doesn't for us.

Posted April 28, 2009 at 9:11 PM | Permalink | Reply

craigswright

Correcting the times is problematic. You then have to explain that you have been changing file access times but that you only did xx. A good lawyer can have a field day with this.

Posted April 29, 2009 at 9:33 AM | Permalink | Reply

forensicrob1

Quoted from my previous comment, "When you perform these steps, the file's access date never actually gets changed. '' nothing gets written to the drive."
In my opinion:
Obtaining accuracy dates + not writing to the disk = no field day for a lawyer
I would prefer doing this to the HELIX method of changing the access dates and losing that valuable information for future use.
But, I don't have to defend this in court, so I will defer to your judgement in this blog.
Rob Zirnstein
President
Forensic Innovations, Inc.
http://www.ForensicInnovations.com

Posted April 29, 2009 at 10:14 AM | Permalink | Reply

keydet89

Craig,
> There are ways of accessing files in Windows
> without altering timestamps, but most of these
> interfere with the operation of a live system.
Can you elaborate on these "ways"?

Posted April 29, 2009 at 4:10 PM | Permalink | Reply

craigswright

When you perform these steps, the file's access date never actually gets changed. '' nothing gets written to the drive."
This is not correct, you are altering metadata and then resetting it. This is in fact changing it multiple times.
All while this is occurring, memory and other volatile data is being changed.

Posted April 29, 2009 at 4:19 PM | Permalink | Reply

craigswright

> There are ways of accessing files in Windows
> without altering timestamps, but most of these
> interfere with the operation of a live system.
Can you elaborate on these "ways"?."
You can carve a file from the raw disk image to a remote computer. Using dd and netcat can achieve this. Start with coping the drive metadata to a remote host, analyse it there. dd the file using the bit offset.
The issue is not that you can do this. There is an order of volatility in examining live systems. Something is always changed and lost. The memory on the system is altered, the pagefile, the network status all change.
Think of this as a forensic uncertainty principle. The more you try to keep one thing the same on a live system, the more you change.
Hence by extracting the file intact to view on a remote system, you have lost volatile data ''" the point of live forensics.
We need to think of a wider world than the disk alone. Otherwise we may as well just pull the power cord and lose the data anyway.

Posted April 29, 2009 at 4:53 PM | Permalink | Reply

craigswright

forensicrob1,
I have installed and run your software overnight. You are accessing metadata, not the file itself. Hence why you can say that you don't change anything, as you are not viewing the file. Also, you are NOT accessing the file. You can not see an image, you can not analyse the behaviour of a dll in memory.
What you are doing is confusing an e-discovery process with live analysis and forensic incident response.
Running FIFind.exe changes the "explorer.exe" process in memory. It accesses dlls in memory and has a significant disk footprint.
Installing this toolkit changes the drive it is installed on. This means you have significantly altered the system. In a live investigation, you can not expect the FI tools are going to be installed already.

Posted April 29, 2009 at 5:03 PM | Permalink | Reply

craigswright

Now, if you look at what you are doing in Helix in live analysis mode, you have the "Scan for Pictures from a live system" function for instance. This allows the investigator to view the content of the image.
This of course changes the access time. What you are doing here is assessing which systems need to be imaged and analysed further.

Posted April 29, 2009 at 11:21 PM | Permalink | Reply

forensicrob1

Craig,
Your assessment of what FI File Find (FIFind.exe) is accessing is incorrect. It is opening each file and examining the contents in order to accurately identify the file. Before opening the file, it also collects system metadata on the file to determine its system attributes, file size, whether it has alternate data streams, etc.. The primary purpose of this software is to correctly identify 3,312 types of files. It includes a few types of previewers, to help analyze files, but it is not designed to be just a file viewer. It does include a multimedia previewer that displays the more common Windows types of images. It does not modify explorer.exe. It adds an entry to the file and folder context menus. Explorer.exe is probably caching those additions in memory. It wouldn't be possible to identify so many types of files accurately without its large disk foot print. But it wasn't designed for minimalist live forensics. It probably identifies far more types of images than Helix, because that is what it was designed to do so that the investigator doesn't miss them in an investigation.
If you care about the volatile data, then you should be using applications with very small foot prints to take snap shots of that data before you use the more powerful tools that perform more complex tasks. What's the point in saying that our software has a big foot print? All applications will modify the volatile data. The software with less features happens to modify it less.
You changed the scope of our conversation in order to win your argument. We were only discussing the access date getting changed on a file, and how to avoid that. Lets play nice and finish that subject. Your welcome to start another blog entry on FI TOOLS, and describe what it does well, what it isn't designed for, provide screen shots, etc.. I think that would be a more appropriate place to discuss its foot print and effects on the system.
So, you tried out our software. Did you find that it kept the access date intact or did it change it?
Rob

Posted April 30, 2009 at 4:31 AM | Permalink | Reply

craigswright

Rob,
FI installs on the disk. This is not what you want from a Live investigation. I did not state that it modified explorer.exe, but that it links to it in memory.
"you should be using applications with very small foot prints to take snap shots of that data before you use the more powerful tools"
Which is the reason for Helix Live. Your tool is the more powerful one after the event. I can see using FI on an image, but not for Live analysis.

Posted May 7, 2010 at 12:05 PM | Permalink | Reply

rob

After i have an image of the physical memory , how can i proced to the get evidences from this image. i did the image just saying live acquisation button then i have it in my desktop's folder. then i like to see what were the processes and other volitile data available that can be an evidence.
please helm me!!

Posted May 17, 2010 at 9:56 PM | Permalink | Reply

Craig S Wright

Hi Rob,
The simplest way is to do a string search.
Have a look at:
http://www.forensicswiki.org/wiki/Windows_Memory_Analysis
http://www.eclipse.org/mat/
http://windowsir.blogspot.com/2009/03/memory-analysis-for-real.html
Tolls such as AESKeyFinder are also of use.

Posted December 29, 2013 at 7:58 AM | Permalink | Reply

Raghida

Can I install Helix 2009 on windows 7