10.9 Program Analysis

When performing a functional reconstruction of a system or application to gain a better understanding of associated digital evidence, it is often desirable to perform empirical testing. For instance, when investigating a computer intrusion, it may be useful to analyze a malicious program (e.g. SubSeven) to see what sorts of evidence it leaves behind on a system. When investigating an online casino, it can be useful to understand more about the inner workings of any gambling programs they distribute to ensure that they do not disclose the investigator's identity or expose the computer in a dangerous manner. The three primary approaches to analyzing a program are to: (a) examine the source code; (b) view the program in compiled form; and (c) run the program in a test environment.

The approach of examining source code was used in United States v. Hersh after digital evidence examiners were unable to decrypt files that they believed contained child pornography.

... encrypted files found on a high-capacity Zip disk. The images on the Zip disk had been encrypted by software known as F-Secure, which was found on Hersh's computer. When agents could not break the encryption code, they obtained a partial source code from the manufacturer that allowed them to interpret information on the file print outs. The Zip disk contained 1,090 computer files, each identified in the directory by a unique file name, such as "sfuckmo2," "naked31," "boydoggy," "dvsex01, dvsex02, dvsex03," etc., that was consistent with names of child pornography files. The list of encrypted files was compared with a government database of child pornography. Agents compared the 1,090 files on Hersh's Zip disk with the database and matched 120 file names. Twenty-two of those had the same number of pre-encryption computer bytes as the pre-encrypted version of the files on Hersh's Zip disk. (Unites States v. Hersh)

Based on these findings, the court was convinced that the encrypted files contained child pornography.

The remainder of this section focuses on simple methods of running a program in a test environment. A convenient approach to creating a test environment for program analysis is to use VMWare,^[32] a program that runs one operating system in a window on another operating system, creating a virtual machine. For instance, Windows 2000 could be installed and run in a virtual machine using VMWare on Windows XP. The supporting operating system, in this case Windows XP, is protected from any actions taken in the Windows 2000 virtual machine. Similarly, Linux can be installed and run in a VMWare virtual machine on Windows.

Once a suitable test environment has been created, it is advisable to create a baseline of the system. By comparing this baseline to the system after the program of interest has been executed will reveal what changes the program made to the system, including file creation, system file alteration, and Registry modifications. For instance, changes to the Registry can be viewed by comparing it against a baseline using Regsnap.^[33] Similarly, Tripwire^[34] can be used to create a file system baseline and show alterations after the program of interest has been executed. File system activity can also be reconstructed after the act using the Windows search feature or using one of the digital evidence analysis tools mentioned earlier. Alternatively, Registry and file system activities can be observed in realtime using Regmon and Filemon.^[35]

In some cases it may be desirable to observe processes and network traffic related to a given program. Details about processes and network connections can be observed using various tools from Sysinternals.com. More details about processes can be seen using Strace for NT.^[36] Network traffic can be captured and analyzed using the tools and techniques described in Chapter 16.

^[32]http://www.vmware.com

^[33]http://www.webdon.com

^[34]http://www.tripwire.com

^[35]http://www.sysinternals.com

^[36]http://razor.bindview.com/tools/