10-4 COPY THAT

10-4 or COPY THAT

This article will discuss the idea of why perform a forensic file copy for evidence as apposed to drag and drop.

Disclaimer: The mention of any program, website or algorithm in no way should be taken as an endorsement of same. And in some cases, I may even point out a flaw or limit to its actions.

Before we start, let me say. If you are doing any kind of forensic file analysis for possible adjudication or court proceeding and are using Windows explorer to copy files which are or may be used as evidence, get another job.

Identify Evidentiary Data/File(s)

Everyone who deals with “digital evidence” should be aware that no matter what or when you obtain the evidence, your ultimate goal or expected end point is to present this evidence in court, unchanged, unaltered, and with proper history of how/where it came from. So treat all electronic evidence as if it will end up as court evidence. If you don’t do it from the beginning, it will be hard to backtrack later.

Assuming (in optimal cases) we are already working with a forensically sound copy of the original evidence (see the hashing article on how to ensure file integrity). In other instances you may have to work directly on the subject drive, which is the original evidence. In either case, you will ultimately identify a file which contains the information or evidence you wish to maintain and continue to work with. In most cases the data/file(s) you will be working with have already been extracted from a forensic suite and you must now continue to "manually" process them on an individual basis, or some other unique situation outside of the point and click forensic suite.

The next step, after identifying the file is to "copy the file" to a safe location for further analysis or preservation for court. When using the word file, you can also assume in appropriate scenarios, I mean the plural files.

Copy the file. 10-4. Sounds simple.

Once you have identified the file which is, or contains the evidence, you have to determine or set up a destination location to save it to. Lets say, a thumb drive that is going to the personnel department for adjudication. The integrity of this file we consider evidence must be maintained for a possible legal proceeding after personnel adjudication.

Now, copy the file. If you open Explorer, drag and drop the file from source to destination, you should begin looking for another job. Because if you did it this way, a good (even poor) attorney will take you to the cleaners using drag and drop in Explorer.

So what/how should you proceed to copy evidentiary files from point A to point B.

FORENSIC FILE COPY(ing)

Quick thought. Consider there are two types of (forensic) file copy programs. Those which require installation on the hard drive, and those which don't require installation.

Programs that require installation.

If your preferred copy program is one that requires installation on the hard drive, it will, when it is "installed" at a minimum copy files to the hard drives directory structure, thus altering the contents of the hard drive. It will most likely also modify the registry entries on the computer. And last but not least, the installation process may also overwrite some important deleted data. If this "installation" process takes place on the suspect computer, do you really want to have to explain that to an attorney? Not me. However, if you are working from your own forensic machine/drive this type of program which requires installation is OK. So determine which type of copy program you will use in different situations.

Programs that DO NOT require installation.

This type of program is often considered a stand alone program. Once it is set up or extracted from its distribution location, it can be run without any installation on a hard drive. This means it can be copied in its entirety to a thumb drive, CD-Rom, a network mounted drive or other media and taken to the subject drive and run without being "installed" on the subject computer.

In more direct terms, it can be run WITHOUT placing software on a subject drive or editing the registry, or overwriting potential deleted data on the subject machine. A good evidence proceedure. Don't alter the subject drive.

My preferred option is to use copy software that does not require installation, can be copied to a thumb drive, and run from that drive without installing on the drive. This way, you only have to learn one program, and use it on your own computer, or use it on a subject machine. Why use two programs when one will do?

Copy Considerations

KNOW WHAT AND HOW YOUR COPY PROGRAM WORKS AND ITS BENEFITS, FLAWS, OR PROBLEMS. Common sense, YES/NO?

Regardless of the software you use, installed, or stand alone, there are a few things to consider about the files you are about to copy. The original state of the files data, and how the copy program handles the data and meta data of the file.

Can it be scripted? In other words, can the program be put or used in a batch file to perform unattended operation. In large cases, (in some instances, I have been involved where we process 20 or more computers at a time), you may have to start a process and move to the next computer before the current process is completed. In most cases, it is difficult if not impossible to script a GUI program. So in this case, maybe command line might be more useful.

Can it identify files with long file names? Long filenames are those files which could contain unicode characters, but more often are those whose combined path/filename length is greater than 255 characters. You never know what files you might find on a subject file system. People run away with file names, and end up with names as long as War and Peace. Know in advance if your program can identify and copy those files. In some tests, I saw copy programs which might identify a longfilename folder, but only listed it as an error log and did NOT copy the files. I also saw one program which found longfilenames, and processed them, BUT listed the paths using their 8.3 names. I would hate to have to explain that alteration to a non techie. Is this a program you want to use?

A filename of 277 characters. folded here for ease of viewing D:\TMP\UTF_LFN_FILES\top_of_lfn_folders\first_of_many_long_filename_folders\second_of_many_long_filename_folders\third_of_many_long_filename_folders\ fourth_starting_at_140_characters_of_longfilename_folders\fifth_folder_starting_at_188_characters_of_longfilenames\begin245.BAT

Can it identify and/or copy Alternate Data Stream (ADS) Files? Some files contain alternate data streams. I can think of a number of reasons I might want to hide sensitive data in an ADS. Suppose key passwords are held there. Does your copy program locate and copy the ADS. If not, what data are you missing. Did the copy program even tell you that there were ADS's that it didn't copy, or did it not even see ADS's. You would be surprised at how many "forensic" copy programs don't show ADS's. Most do copy even though they don't show it. But some don't.

An alternate data stream attached to a .bat file. D:\TMP\UTF_LFN_FILES\top_of_lfn_folders\first_of_many_long_filename_folders\second_of_many_long_filename_folders\third_of_many_long_filename_folders\ fourth_starting_at_140_characters_of_longfilename_folders\fifth_folder_starting_at_188_characters_of_longfilenames\begin245.BAT:ads.txt

How does the copy handle MAC (Modified, Access, Create) dates? You have two things to consider here. When it copies the file, does it recreate the Create and Modified date of the original. Most do. But you need to check that. However, here is the tricky one. What happens to the last Access date. On most computers the update last access date key is turned off. So a copy from computer A, does not alter the last access of the source file. But do you know this ahead of time?

Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem Name: NtfsDisableLastAccessUpdate Type: REG_DWORD Value: 1 A value of 1 turns last access off. Value of 0, sets last access update.

Notice all three dates are captured. path shortened for legibility D:\TMP\UTF_LFN_FILES\...\begin245.BAT | 1076| 06/26/2009|08:18:55:312c|02/25/2009|08:30:45:640w|02/19/2019|17:33:28:542a|EST|

Do you know if last access is off or on on your machine, or on the machine you are copying files from?

Regardless, you should consider if your copy program does the following. If possible, do not alter the last access of the source file. This is to preserve the original access time on the source drive. And second: does the program set the MAC dates of the copy to those of the original. It would be nice in court if the MAC dates showed to the jury were the originals. DAH!

Do you have a good copy? And finally, and very important. No matter what/how you copy, is your copy true? This generally means does the copy program perform any type of verification. Usually a hash value. In a significant number of tests, I have found that very few perform any type of hashing to confirm a good copy. How do you testify to that. So consider some sort of hashing. It is easy enough to do it as a seperate step. But if it is built into the copy program, that would be nice.

source: D:\TMP\UTF_LFN_FILES\top_of_lfn_folders\....\begin245.BAT | 0071D6D738D1E2DB3115BDEE23478117 destination: d:\tmp\junk_del\top_of_lfn_folders\....\begin245.BAT | 0071D6D738D1E2DB3115BDEE23478117 |[OK] No apparent mismatches in the copied hashes

Logging Does the program create some sort of log of its operation? Is the log useful. Meaning is it just kind of convoluted text format, or proprietary format. Of does the log contain easily readable, and "importable" data to a spreadsheet or data base. Does it produce the hash values of the files. Does it identify failures? These are all questions the defense may ask.

Started Wed Feb 27 15:07:45 2019 GMT, 11:07 Eastern Standard Time (EST/EDT:5*) Command line: C:\UTILS\NTUTILS\UPCOPY.exe -p . -f begin*.bat -d d:\tmp\junk_del --logfile=logs -H hash_logs Count Files indicates: 1 files to process, approx 1,076 bytes Processed 1 files, 1,076 bytes: Copied 1 files, 1,076 bytes:

Check out some of my software on my homepage for forensic cataloging (file listing), hashing, copy, email header processing, secure file deletion, and others.

DMARES.COM A FORENSIC COPY PROGRAM

For questions or answers (no flames please) regarding the hashing software, the NIST data records on my site, work007 (at) dmares.com.

Author - Dan Mares. Dan is a respected Friend and very knowledgeable digital forensic investigator.

Dan Mares founded Mares and Company, LLC in 1998 after retiring from a 27-year career as a federal law enforcement agent. During that time he became interested in and obtained training in computer science. He began developing software programs designed to analyze large amounts of data retrieved from mainframes. Those programs were the precursors to the current Maresware data analysis software. Around 1986, he began working in the area of what is now termed 'computer forensics.' In the search for tools more suitable to the specific needs of computer forensic investigations, he began developing software that was later called Maresware computer forensic software.

While serving as a federal agent, Dan assisted in the development of the Seized Computer Evidence Recovery Specialist (SCERS) course at the Federal Law Enforcement Training Center in Glynco, Georgia. He also served as a guest SCERS instructor. He also assisted in the development and teaching of the Basic Data Recovery and Advanced Data Recovery classes at the National White Collar Crime Center.

A few of the organizations he has appeared before as guest speaker include: International Association of Computer Investigative Specialists (IACIS); University of Texas, Austin.; Kennesaw State College; U.S. Secret Service; FBI Academy in Quantico, Va.; High Technology Crime Investigation Association(HTCIA); and Norwegian National Police Academy.

#Forensiccopying #DigitalEvidence