Forensic Acquisition Utilities
Copyright © 2002-2016 George M. Garner Jr. <gmgarner (at) gmgsystemsinc (dot) info>
Revised April 25, 2016.
Project purpose and components:
This is a collection of utilities and libraries intended for forensic or forensic-related investigative use in a modern Microsoft Windows environment. The components in this collection are intended to permit the investigator to sterilize media for forensic duplication, discover where logical volume information is located and to collect the evidence from a running computer system while at the same time ensuring data integrity (e.g. with a cryptographic checksums) and while minimizing distortive alterations to the subject system. The components of this package are not intended to preclude all changes to the subject system while the evidence collection process is under way. A third party hardware or software write blocker should be employed in those circumstances where it is deemed necessary to guarantee that no changes occur to the subject volume prior to and after the imaging process.
What’s new in this release?
April 25, 2016:
signtool.exe -v -r --sign c:\myprojects\*.exe;*.dll --cert my.cer --cryptsum sha1 --cryptsum sha256
signtool.exe -v -r --sign c:\myprojects\*.sys --pfx my.pfx --cross_cert GlobalSign_Root_CA.crt --cryptsum sha1 --cryptsum sha256 --password secret --require_strong_signature --description "Windows system component" --more_info "http://www.mycompany.com/"
signtool.exe -v -r --timestamp c:\myprojects\*.exe;*.dll --timestamp_server Verisign --rfc3161_timestamp --cryptsum sha1 --cryptsum sha256
November 28, 2015:
strip.exe -v myprogram.exe --section debug
strip.exe -v myprogram.exe --section debug --os_major_version 5
--os_minor_version 2 --image_major_version 5
--image_minor_version 2 --subsystem_major_version 5
June 15, 2015:
September 14 2014:
August 30, 2013:
dd.exe -v if=\\.\PhysicalDrive0 of=myimage.bin conv=noerror --log --cryptsum sha_256 –localwrt
August 4, 2009:
July 31, 2009:
September 19, 2008:
August 29, 2008:
· Volume_dump displays storage device properties such as the manufacturer, vendor ID and serial number, among other information. Certain USB storage devices may return uninitialized data for the serial number which may include control characters and other values that do not print or display properly. This error condition is handled in versions of Microsoft Windows™ prior to Windows™ Vista. But Vista passes the uninitialized data up to the application. Build 2374 handles this error condition.
May 14, 2008:
November 30, 2007:
What’s included in this release:
Included in this release are x86 and x64 versions of the following modules:
1. Dd.exe: A completely new implementation inspired by the popular GNU dd utility program.
2. Volume_dump.exe: An original utility to dump volume information and drive information and USN journals.
3. FMData.exe: An original utility to collect files system metadata, to produce and verify security catalogs (cryptographic hash sets) using one or more cryptographic hash algorithms and to verify system binaries using the system file checker (SFC) API.
4. Wipe.exe: An original utility to sterilize media prior to forensic duplication.
5. Nc.exe: A completely new implementation of the popular Netcat utility inspired by the original version created by Hobbit.
9. Fauerror_xxx.dll: A series of dynamic link libraries (dll’s) that contain the localized language strings for FAU output. There is one dll for each locale supported by the FAU.
This software requires Microsoft Windows 5.0 (Windows 2000) or later. Versions of Microsoft Windows prior to Windows 2000 will not be supported. The software has been tested on Microsoft Windows 2000 Gold and SP1-SP4, Microsoft Windows XP with SP2 and SP3, Windows XP Home SP2, Microsoft Windows Server 2003 Gold and SP1 and SP2, and both x86 and x64 versions of Microsoft Windows Vista with SP1 and SP2, Microsoft Windows Server 2008, Microsoft Windows Server 2008 with SP2, Microsoft Windows 7 and Microsoft Windows Server 2008 R2.
This release is distributed only in binary form and includes both Intel x86 and AMD x64 binaries. FAU binaries may be downloaded from here. A detached PGP signature of the compressed zipped binaries is available from here. Decompress the ZIP archive into a folder. Download the PGP detached signature and verify the ZIP archive. The decompressed binaries then may be burned onto a CDROM disk or other removable media. To run the accompanying executables, open a command prompt and navigate to the FAU installation folder. Type the appropriate command and press enter.
Program executables are optimized to minimize their memory footprint. Programs optimized for reduced size may be slower than the same programs when optimized for speed.
Microsoft CRT version 10.0:
This release requires version 10.0 SP1 of the Microsoft C/C++ runtime libraries. Redistributable copies of the Microsoft runtime libraries are included in the FAU distribution. They also may be downloaded independently from http://www.microsoft.com/download/en/details.aspx?id=8328 (x86); and http://www.microsoft.com/download/en/details.aspx?id=13523 (x64).
Operating System Requirements:
This software requires Windows™ XP or later version of Microsoft Windows™. Both x86 and x64 versions of Microsoft Windows™ are supported.
The Forensic Acquisition Utilities are distributed under the GMG Systems, Inc. Open License. The Open License permits the use of the FAU for both commercial and non-commercial uses, subject to certain restrictions.
Downloading the Forensic Acquisition Utilities:
The current release Microsoft Windows binaries of the Forensic Acquisition Utilities is build 126.96.36.1994, which may be downloaded as a compressed zip file from here. A detached PGP signature of the compressed zipped binaries is available from here.
National Language Support:
The FAU is a fully localized application with initial support for American English, Dutch, French, German, Italian, Spanish, Portuguese and Chinese (PRC). My apologies if I have offended anyone by my attempt to translate the FAU into their language. Any errors in the language bindings are wholly my own. Corrections will be welcomed. I am indebted to Robert-Jan Mora and Christel Verheyden for assistance with the Dutch translation. I am indebted to Alexander Geschonneck and Frank Birkmair for assistance with the German translation and to Silvia Latapie for assistance with the Spanish translation. I am indebted to Tom Zhou and William Ma for the Chinese translation. I am indebted to Daniel Moreira for assistance with the Portuguese translation.
XML schema used by the FAU.
The FAU produces output for many commands in XML format. The XML schema used by the FAU is available here.
The Forensic Acquisition Utilities is a product of GMG Systems, Inc. If you have any questions or to report bugs, please contact GMG Systems, Inc. at support (at) gmgsystemsinc (dot) com.
Over the past several years differing visions of computer or digital forensics have evolved . On the one hand, there are those who view computer forensics as applying narrowly to the analysis of evidence acquired through “proper evidence handling procedures.” The term “proper” is reserved for the acquisition of evidence by forensic duplication (“imaging”) and the term “evidence” generally refers to file system evidence. Often the principle that evidence must be acquired without changing it is stated in absolute terms as a sort of digital “Prime Directive” of computer forensic discovery . (For a more nuanced statement of this principle, compare .) Authors debate whether to shut the system down using the normal system shutdown commands (Robert E. Greenfield, 2002, 74) or by abruptly terminating its power (“pulling the plug”). (Kruze and Heiser, 2002, 5.) But shutting the system down is commonly accepted as the necessary predicate of forensic discovery.
During the same time period, a different vision of computer forensic discovery has emerged, in large measure due to the pioneering work of Dan Farmer and Wietse Venema . This perspective regards the “Prime Directive” as more as an obstacle to digital forensic discovery than as its founding principle (at least as applied to the investigation of malicious within the incident response context).
Since 1999, we have come to remove the phrase “in a manner as free from distortion or bias as possible” from our definition of forensic computing. We believe that by risking digital evidence, investigators are more likely to retrieve additional data and have a better chance of addressing and understanding the problem at hand. (Farmer and Venema, 2005, 194.)
The reason for this rather sharp rejection of classical digital forensic paradigm is because the traditional belief system forces us to discard a good deal of evidence that that cannot be acquired within the traditional framework. By selectively including some evidence and discarding other evidence the classical approach itself alters evidence and thereby risks introducing the very thing which it seeks to avoid, bias and uncertainty. For Farmer and Venema it is better to “risk evidence” by observing a “live” computer system over time than to cling to the illusory “certainty” afforded by analysis of a computer system’s fossilized remains.
A year ago one might well have ascribed the former view of digital forensics to law enforcement and the latter view to security professionals and military intelligence . Today this stereotype appears to be fading. Classical formulations which seemed an absolute bar to “live response” are being reinterpreted to allow what once seemed forbidden . We are witnessing a convergence of interest on the part of law enforcement, security professionals and military intelligence in what is variously may be described as “live forensics,” “network forensics” or “remote forensics.”
The reasons for this convergence are varied but ultimately rooted in the nature of modern computing systems and computer crime. First there is the ubiquitous nature of malicious code, especially virus-delivered malware, within the modern computing environment . This presence raises questions about the provenance of non-volatile computing artifacts that are difficult to answer within the traditional framework .
Advances in cryptography also present vexing problems for contemporary investigations. Encrypted documents have been shown to persist as plain text in volatile memory for some time after the document is committed to disk . If a user currently is logged on to the suspect computer when the investigator arrives on the scene and that user has the right to access encrypted files, an investigator may be able to decrypt the documents without obtaining the user’s password or encryption keys. This opportunity will be lost once the suspect system is shut down.
Then there is the distributed nature of modern computing and computer crime. Also, an investigation may span literally thousands of machines and several continents. Implementing a classical computer forensic methodology would be extremely burdensome and time consuming in many modern investigative contexts.
Finally, there is the fact that crime or other inappropriate activity often targets the most valuable resources. The owner’s of mission critical servers or servers doing millions of dollars in transactions per day may be reluctant to shut their systems down without proof of a compromise (or other compelling reason). These same owners may be unwilling to shut their systems down at all if their systems are only incidentally affected by the matter under investigation, for example if an email is suspected to have been transmitted through one of their servers. Investigators need a way to rapidly identify and acquire items of evidentiary interest while minimizing interruptions to service and potential distortion or other risks to evidentiary integrity.
To the extent that digital forensics aspires to science it needs to come to grips with the notion of uncertainty since this notion pervades the process of scientific discovery from beginning to end. If we deny the operation of this principle we cease to be objective and become advocates of a particular party or point of view.
Scientists and jurists have to abandon the idea of absolute certainty in order to approach the identification process in a fully objective manner. If it can be accepted that nothing is absolutely certain then it becomes logical to determine the degree of confidence that may be assigned to a particular belief. (Aitken and Taroni, 2004, 5, citing Kirk and Kingston, 1964.)
If evidence were inherently reliable then there would be no need for forensics. Trust is not the starting point of a forensic investigation but its goal. Forensics sifts the facts in order to determine the confidence level which may be assigned to a particular belief. To this extent, forensics is the art of drawing trusted inferences from one or more un-trusted sources by the methodic application of reason to the evidence.
It is the application of a method based upon reason and observation that distinguishes forensics from the naive approach to evidence. Yet this same method may itself be the source of bias and error. The investigator’s training and method instill in him certain preconceptions concerning the nature and scope of a case, of what evidence is relevant and how it should be collected. These assumptions select and shape the evidence and thereby shape the results, for better or for worse.
The conventional approach sifts the facts by discarding volatile evidence from the outset. Volatile evidence is faulted because it cannot be collected without alteration (given the current state of technology). Yet the assumption that volatile evidence collection methods make volatile evidence inherently more unreliable than non-volatile evidence collection is just that, an assumption. Classical evidence collection procedures also modify evidence, and in some cases extremely pertinent evidence, namely by discarding it. To say that discarding 500+ MiB of memory does not alter evidence is to use words in a manner that is contrary to their ordinary meaning.
If it be accepted that all digital evidence collection methods result in at least some degree of alteration to the evidence (considered as a whole), then it seems possible to ask which evidence alterations will lead to the minimum distortion of the facts as applied to an individual case. It is after all not evidence alteration per se but strong misleading evidence which renders evidence unreliable. Maybe the classical approach will lead to the minimal misleading evidence in some cases. But in the light of the broad diffusion of anti-forensic techniques , the classical approach clearly is not always the best way to go.
Discarding volatile evidence is only one possible way of sifting the facts. Another way is by fusing evidence obtained from multiple sources (e.g. hard drive, memory, network, external records). We believe that evidence fusion offers a clear advantage in a number of contemporary contexts, such as the investigation of malicious code and related economic crimes. In other cases where the relevant facts are primarily historical in nature and likely saved to persistent storage the classical approach may be a better option.
The Forensic Acquisition Utilities does not attempt to resolve the problematic of forensic methodology. Rather, it assumes that both the classical and “live” approaches are valid in their proper application. Unlike in the sphere of religion, a scientist is permitted to subscribe to multiple belief systems while applying each one according to its heuristic value within the context of an individual case. It is for the investigator to weigh the probabilities and determine which method is more probable to arrive at a result which corresponds to the facts[†]. It is hoped that the tools accompanying this release will be found useful in either context.
dd.exe -v if=\\.\F: of=192.168.0.1 conv=noerror --iport 3000 --comp lznt1 --log --cryptsum md5 --cryptsum sha1
nc -v -n -L -p 3000 -s 192.168.0.2 --decomp lznt1 -O h:\servername\filename.img –localwrt
Note that the log and cryptographic checksum files also will be transmitted over separate sockets to the same destination TCP port (3000 in the example above).
dd.exe -v if=\\.\F: of=h:\filename.img conv=noerror --chunk 2GiB --log --cryptsum md5 --cryptsum sha1 –localwrt
The output from this command will include a contents file (“*.contents.xml”). Use the ‘-g’ option together with the contents file as input to reassemble the “chunks” into a single image.
dd.exe -v -g if= filename.contents.xml of=fdrive.img --log --cryptsum md5 --cryptsum sha1 –localwrt
dd.exe -v if=fdrive.img of=NUL --cryptsum md5 --cryptsum sha1
Warning: Malicious code that spreads via writable removable media (e.g. a USB or firewire drive) has become sufficiently common place that many organizations and some government agencies ban their use from the workplace. Forensic acquisition of volatile evidence to removable media presents many of the same risks. If you acquire volatile evidence to removable media without taking proper precautions you subsequently may find that you were the one who spread the infection to the entire network, or that you yourself have become a part of the global botnet. Do not acquire volatile evidence to removable media unless you understand the associated risk of malicious code transmission via removable media and have implemented a strategy to mitigate that risk. Do not rely exclusively on commercial antivirus products as a risk mitigation strategy. At a minimum a mitigation strategy should include the following elements:
§ Always run volatile evidence collection tools from read-only media.
§ Do not use the same removable evidence collection media on more than one suspect computer.
§ Copy the evidence from the removable media to your forensic workstation using a “sacrificial” computer as an intermediary.
§ Boot the sacrificial computer from read only media (e.g. a boot CD) and use a network tool such as Netcat or FTP to copy the evidence over a closed network for subsequent storage and analysis.
§ Reboot the “sacrificial” computer before attaching the next removable evidence collection device.
 Eoghan Casey, T h e need for knowledge sharing and standardization, Digital Investigation 1 (2004), 1-2.
 Good Practices Guide for Computer Based Electronic Evidence (ACPO, 2003). http://www.4law.co.il/Lea92.htm.
 U.S. Department of Justice, Forensic Examination of Digital Evidence: A Guide for Law Enforcement. National Institute of Justice Special Report, Office of Justice Programs (2004). http://www.ojp.usdoj.gov/nij/pubs-sum/199408.htm.
 Robert E. Greenfield, The Liturgical Forensic Examination: Tracing Activity on a Windows-Based Desktop in Albert J. Marcella and Robert S. Greenfield, editors. Cyber Forensics. A Field Manual for Collecting, Examining, and Preserving Evidence of Computer Crimes (New York, 2002).
 Warren G. Kruze II and Jay G. Heiser, Computer Forensics. Incident Response Essentials (New York, 2002).
 Dan Farmer and Wietse Venema, Forensic Discovery (New York, 2005).
 AOL/NCSI Online Safety Study (2004). http://www.staysafeonline.info/news/safety_study_v04.pdf.
 Ester George, UK Computer Misuse Act - the Trojan virus defence Regina v Aaron Caffrey, Southwark Crown Court, 17 October 2003, Digital Investigation, 2 (2004). http://www.compseconline.com/digitalinvestigation/trojancase.pdf.
 Brian Carrier. Open source forensics tools (2002). http://www.digital-evidence.org/papers/opensrc_legal.pdf.
 Colin Aitken and Franco Taroni, Statistics and the Evaluation of Evidence for Forensic Scientists. Second Edition (Chichester 2004).
 P. L. Kirk and C. R. Kingston, Evidence evaluation and problems in general criminalistics. Presented at the Sixteenth Annual Meeting of the American Academy of Forensic Sciences (Chicago 1964).
 Good Practices Guide for Computer Based Electronic Evidence (ACPO, 2006), http://www.acpo.police.uk/asp/policies/Data/ACPO%20Guidelines%20v18.pdf.
 How Online Criminals Make Themselves Tough to Find, Near Impossible to Nab, http://www.cio.com/article/114550.
[†] Ideally we would like to base our choice of method on empirical evidence. Unfortunately there are few if any studies quantifying the error rate of competing digital forensic methods as applied to specific types of cases. Faced with the paucity of numerical data, the investigator will have to rely upon subjective assessments of probability as measures of belief. (Aitken and Taroni, 2004, 21.)