10-4 or COPY THAT

The truth is out there
So make sure your software can find it.

First authored Feb. 2019. Long time ago by computer standards.
Updated Oct 2, 2024. However, by the time you read the article, a lot of time may have passed and the software that was tested may have been updated and now just might pass the tests. However, you should conduct tests of your own to see if the current version passes your tests and meets your needs.


Here are a few articles you might like to read in the order listed. But before reading them, think about this small difference: the difference between "processing the evidence", and "conducting the forensic investigation". I think these articles are more targeted to the processing of the evidence rather than the direction you use to conduct the investigation. They may be very similar but no cigar.



CAVEAT
Your know what that is: "a modifying or cautionary detail to be considered when evaluating".

The cautionary detail is that most of my testing took place during 2019-2022 time frame and I suspect that some of the versions of the software being tested has been updated, modified, fixed. Not to say, the problems I found have been fixed, just that there are newer versions out there, and maybe, just maybe the short comings I found may have been fixed. Just saying.

However, as I see people recommending software I have tested, I may occassionally check for a current version of the recommended package, and again test it against my requirements. In some cased the shortcommings are fixed, in most not.


Here are a few articles you might like to read in the order listed. But before reading them, think about this small difference: the difference between "processing the evidence", and "conducting the forensic investigation". I think these articles are more targeted to the processing of the evidence rather than the direction you use to conduct the investigation. They may be very similar but no cigar.

Before you get into this article, you might read these associated sequence of articles.

Start here:

Inventory/Catalog files  Creating an inventory of evidentiary files
the one you are on: Forensic file copying  Article tests over 40 "forensic" file copiers
Forensic Hashing  Article tests over 30 "forensic" hash programs.
ZIP-IT for forensic retention  Article test a few zipping programs and
ZIP_IT_TAKE2  More tests for your zipping capabilities.
ZIP FILE/container  Hashing your zip container reliably
MATCH FILE HASHES  Demonstrates hash matches using Maresware.
A HASH software buffet   How-to use Maresware hash software


Preliminary case information which determines why I chose the items to test.


A little cyber investigation rant.

Even those of you doing cyber forensics/investigations or intrusion investigation must realize and understand that even those investigations involve some of the basic forensic steps or activities. So even your corporate cyber investigation will require you to accurately copy any files/data which you are working with. The capability to properly and accurately copy any possible forensic evidence for analysis is important. Even the most basic inquiry would have need for a reliable means to make accurate copies of the data being anlysed or preserved. So don't disregard this article.

Also, since I tested the software on my WIN10 machine using an NTFS file structure, some of the requirements are designed to fit that environment. So if your environment or needs are different, you may be very comfortable with a product that failed my tests. Also, if your legal requirements are not as strict as those i set up for my tests, have at it. I just wish to point out, that if a product failed my test, and you overlook that aspect, hope the opposition attorney also overlooked the same requirement. We all have different needs, I merely tested what I thought might be easily attached it court.


Read this article and raise your forensic intelligence level a few points. 😄

You will see throughout this article, a lot of discussion is repeated over and over. This is mainly because as I wrote the article, new ideas kept coming to mind, and I just added that information. So I just rambled on.

This article will discuss the idea of why perform a forensic file copy for evidence as apposed to the traditional "drag and drop". It will point out some of what I consider simple NTFS related evidentiary requirements and tests you can perform to ensure that under the described scenarios your software can/will make good forensic copies of the data files. It also points to some tests I have run and determined that over 90% of the more common "forensic" copy programs will fail some of my evidentiary tests. And if you think about it (I know its a stretch) when you zip files for archiving or delivering to reviewers, you are also copying files. So take a look at the article ZIP_IT  also.

Before going any further, take this challenge  to see if your hash, copy, zip software passes the test. This page also has links to test files which I used to run my test.

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.

Table of Contents:
  -  TEST RESULTS  Table of programs tested.
  -  Suite stuff  Suites don't do it all.
  -  Identify Evidence  for the forensic copy.
  -  Forensic File Copying  to install or not to install the copy program.
  -  Last Access Date Discussion  why set it to ON.
  -  Cloud Storage and Evidence  whats in the clouds?

Preliminary case information which determines why I chose the items to test.

First case: You have a situation where you can seize the entire computer, or make a full bit image of the drive then some of these test requirements will be easily met using a suite. See Suite stuff   below. However, there are situations which will be a little more restrictive, and which will cause you (or rather your software) to be more restrictive in what and how you process the evidence. That situation will be explained here, and again below, just so you get the idea behind the topics I chose to perform the tests around. I think (I know thinking is bad), that testing software under these more restrictive scenarios will show that the software can not only perform in a more restrictive environment, but also in one in which you have complete control.

Today, Sept. 12, 2023, I just had another discussion with an investigator that brought up another situation which should be considered. It is the situation where you have your work data on a seperate drive, maybe a USB, or work drive, and then you want to copy that terabyte(s) of data to a final resting place. The copy process may go slow, have copy errors due to USB problems, etc etc. So just in normal day to day evidence process and manipulation you may need a good reliable evidentiary copy program. So make sure your copy software under normal work conditions performs correctly and reliably.


So lets begin:

The tests were performed on an NTFS file system because I believe that is the most common file system used by corporations today. It also offers the more items with which we will perform the tests.

So number one is the fact that the software will be able to find unicode file names. Not necessarily display in full unicode format, but merely find and process those items.

Then, second because we are on NTFS files system, we must be able to find and process long filenames. Those filename paths greater than 255 characters. You will be surprised at how many programs can't do that.

Third, again because NTFS, we will ass ume that the owner of the computer system, (usually a corporation) has last access update turned on. The last access update may or may not be important to your investigations, but if it is turned on, your program should be able to NOT tamper with the file/evidence last access date.

And fourth and final: again because of NTFS, we should be able to find, identify, and process where necessary any alternate data streams. Consider a porn investigation where the user downloads porn from various sites. Did you know, that some browsers (I'm not telling you which, thats for you to find out) actually store in ADS's the original URL and other information of the download. Might be very interesting in porn or other internet investigations.

Also, you must consider when copying from suspect to a work drive for transmit to your office, that the copy program retains ALL original file dates so as not to corrupt or influence the analysys.

If you perform a bit-image of the drive using a suite, most of these items above will easily be identified and located as evidence. However, in our test scenario, we are sitting at a corporate server where we can ONLY process/examine/image/copy (call it what you will) that directory tree belonging to the suspect. So this fine line refinement and restriction must be considered when testing our software. Period....


TEST RESULTS

Quick jump past the test results of the article.

Here is a study I performed on about 40+- "forensic" copy programs and the results. Generally I only tested the free or eval versions, as I'm not about to pay for a piece of software just to add it to my tests. If anyone wants to provide me a paid version of the software, feel free, and I'll test it.
I attempted to be as accurate and consistant in my testing, but stuff happens. So if you test any of the mentioned software, and obtain a different result, please let me know so I can retest.

Notice that only 2 passed all the tests. However, many people ignore the last access date requirement. But will the defense allow you ignore that piece of evidence?
Less than half passed the copy requirements of alternate data streams. What evidence might be left behind if you don't copy all the ADS's. Especially any evidence that might be missed when you are creating a final zip container for retention or delivery to the defense.


An alternate data stream evidentiary discussion:

Lets say you are doing a pornography investigation, and find a file with a provacative name within the suspects pictures.
PIECE_OF_TAIL.mp4     72,788,245  01/29/2022 08:19:20:653w
Looks like an interesting piece of evidence.
You might be wondering where did that file come from?
   -    did you know that if the file was downloaded from the web, depending on the browser, the information might be right in front of you in an alternate data stream?
PIECE_OF_TAIL.mp4                       72,788,245  01/29/2022 08:18:56:678c  A.....
PIECE_OF_TAIL.mp4:Zone.Identifier               95  01/29/2022 08:18:56:678c  .adata
Lets see whats inside that alternate data stream that was created by firefox browser when the movie was downloaded.
I've taken some literary license by extracting the alternate data stream data to a "real live" file using the copy_ads.exe program so it could be seen. Here is the contents of the ADS file.

   D:\TEMP>type "PIECE_OF_TAIL.mp4[Zone.Identifier]"
   [ZoneTransfer]
   ZoneId=3
   HostUrl=https://www.dmares.com/maresware/graphics/PIECE_OF_TAIL.mp4

   -    Don't you think knowing the information within that alternate data stream might be helpful to your investigation?
   -    Wouldn't it be nice if you saved that piece of information in the zip file when you zipped the evidence?
   -    Do you know that a number of zipping software programs WILL NOT include that piece of evidence in the final zip file???
   -    Do you know that a number of "forensic" copy programs won't copy the alternate data stream from pointA to pointB of you evidence work directory???

To continue:
You will notice that there are some suites and zip programs included in the tests.

If a suite is included I only tested that part of the suite which would equate to a simple copy from tree/directory point A to point B. No imaging was done. Purely a logical tree copy from A; to B. Most Suites, in/on a true forensic image will work OK. But that is not what I was testing.

The study was done using larger more inclusive versions of the "challenge" images mentioned below. Totally non-scientific, but somewhat practical.

The column headers are:
  -  LFN:            - (does it properly find and hash long filename files > 255 character path/names)
  -  UNICODE:  - (does the program properly identify and process Unicode filenames)
  -  ADS:             - (does it find and process Alternate Data Streams, great hiding places)
  -  RESET LAST ACCESS:    - /source/destination (does it properly reset original last access, and properly set all dates)
  -  MAC:           - (which of the MAC dates WAS properly reset)

Those whose items show 1/2 pass means they didn't always pass either the LFN or ADS test.

Also, let it be known, that of those items tested, a number of zip programs were included. After all, what is a zip program but a fancy copy item.
Results sorted, and program names omitted to protect the unworthy.

    UNICODE     |LFN       |ADS       |Reset SOURCE Access   |RESET DEST ACCESS   |[MW]AC reset dest
    
    PASS        |PASS      |PASS      |PASS                  |PASS                |PASS
    PASS        |PASS      |PASS      |PASS                  |PASS                |PASS
    PASS        |PASS      |PASS      |N/A mount RO          |FAIL                |MW
    PASS        |PASS      |PASS      |FAIL                  |PASS/2              |MW
    PASS        |PASS      |PASS      |FAIL                  |PASS                |PASS
    PASS        |PASS      |PASS      |FAIL                  |PASS                |not tested
    PASS        |PASS      |PASS      |FAIL                  |PASS                |MAC
    PASS        |PASS      |PASS      |FAIL                  |PASS                |MAC
    PASS        |PASS      |PASS      |FAIL                  |FAIL                |MC
    PASS        |PASS      |PASS      |FAIL                  |FAIL                |M
    PASS        |PASS      |PASS      |FAIL                  |FAIL                |M
    PASS        |PASS      |PASS      |FAIL                  |FAIL                |M
    PASS        |PASS      |PASS      |FAIL                  |FAIL                |FAIL
    PASS        |PASS/2    |PASS/2    |PASS                  |PASS                |PASS
    PASS        |PASS/2    |PASS/2    |FAIL                  |PASS                |PASS
    PASS        |PASS/2    |FAIL      |PASS                  |PASS                |PASS
    PASS        |PASS/2    |FAIL      |FAIL                  |PASS/2              |PASS/2
    PASS        |PASS      |PASS/2    |PASS/2                |PASS/2              |PASS/2
    PASS        |PASS      |FAIL      |PASS                  |PASS ?              |PASS MC, A?
    PASS        |PASS      |FAIL      |FAIL                  |PASS                |PASS
    PASS        |PASS      |FAIL      |FAIL                  |PASS                |MC
    PASS        |PASS      |FAIL      |FAIL                  |PASS                |MC
    PASS        |PASS      |FAIL      |FAIL                  |PASS                |MC
    PASS        |PASS      |FAIL      |FAIL                  |PASS                |
    PASS        |PASS      |FAIL      |FAIL                  |FAIL                |MC
    PASS        |PASS      |FAIL      |FAIL                  |FAIL                |M
    PASS        |PASS      |FAIL      |FAIL                  |FAIL                |FAIL
    PASS        |PASS      |FAIL      |FAIL                  |                    |
    PASS        |FAIL      |PASS/2    |FAIL                  |FAIL                |M
    PASS        |FAIL      |PASS      |PASS                  |PASS                |MAC
    PASS        |FAIL      |PASS      |FAIL                  |FAIL                |MC
    PASS        |FAIL      |PASS      |FAIL                  |FAIL                |M
    PASS        |FAIL      |FAIL      |PASS                  |FAIL                |FAIL
    PASS        |FAIL      |FAIL      |FAIL                  |PASS                |PASS
    PASS        |FAIL      |FAIL      |FAIL                  |PASS                |can't run 
    PASS        |FAIL      |FAIL      |FAIL                  |FAIL                |MC
    PASS        |FAIL      |FAIL      |FAIL                  |FAIL                |M
    FAIL        |FAIL      |FAIL      |FAIL                  |FAIL                |MC
    FAIL        |FAIL      |FAIL      |FAIL                  |FAIL                |FAIL

               
  -  1/2 Pass: Usually meant it passed normal files, but failed to process LFN, and/or ADS's within LFN's and/or short filenames
  -  LFN:      Can program find and process files with filenames longer than 255 characters?
  -  UNICODE:  Does the program properly process unicode filenames? 
  -  ADS:      Can program find and process the Alternate Data Stream of a file. Both short and long filename files?
  -  SOURCE:   For hashing, copying, zipping: Does program reset original last access, or update to current date?
  -  DEST:     For copy, zipping/unzipping: Does software reset destination last access to original value?	  
  -  [MW]AC:   For copy, zipping/unzipping: Does software reset destination MODIFIED/WRITE, CREATE, ACCESS dates to original?

If a column is blank, either couldn't test it, or just got lazy and bypassed.

Just a little more intrigue. Here is a partial list of the software tested, and version number (if I saved it). Remember, for the suites, ONLY the simplest tree copy process was used, and not any image copy process. The order here is NOT the same or as inclusive as the result table above. So don't try to match it up, one for one. Do your own testing before the defense does.

    Program - Company                   | Version 

    7-Zip                               |19x
    Autopsy - Sleuthkit                 |14.4
    BCARCHIVE - BCCOPY                  |2.07.1.4
    Belkasoft                           |7.9
    Beyond_Compare                      |4.2.8
    Copy_Handler                        |Jan-44
    Evidence_Mover (NUIX)               |6.2.1
    EXPRESS_ZIP (NCH Software)          |??
    Extreme_copy pro                    |2.3.4
    FastCopy                            |3.8.4
    Forensic Explorer - Export          |5.x
    ForensicCopy                        |1.3
    FreefileSync                        |10.22
    FTK-imager                          |4.5
    Get_Data Forensic explorer /imager  |2.2.0.253
    Hampster-zip                        |4.0.0
    Intell - Vound software             |
    Kroll - kape                        |0.9x
    Magnet_Axiom Acquire-Logical        |eval
    Microsoft XCOPY                     |
    novirus raw_file copier             |1.5
    ntfscopy                            |---
    Paladin - Unix forensic             |7.05
    Paraben                             |E3P2C
    PKZIP                               |14.2
    PKZIP-SECURE ZIP                    |14.4
    richcopy (microsoft)                |4
    robocopy                            |
    safecopy                            |2.6.1
    safecopy-pinpoint labs              |eval
    syncbackfree                        |8.6.7.6
    teracopy                            |3.26, 3_17(2024)
    TotalCommander (tcm951) 6/2020      |951
    ultracopier                         |1.6.1.5
    Upcopy                              |20.x
    VIceVersa                           |eval
    Windows copy/paste                  |WIN10
    WINRAR                              |5.7x
    WINZIP                              |24
    X-Ways                              |17.3
    XL-File Tools                       |4.3

  DMARES.COM home page.
  A TRUE FORENSIC COPY PROGRAM
Associated articles and programs of interest:
  hash  program to calculate hash values.
  HASH_IT_OUT  an article discussing forensic hashing of evidence.
  ZIP_IT  an article regarding use of zipping software for forensics.
  ZIP_IT_TAKE2  an article explaining the testing of zipping software.

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

TOP  

SUITE STUFF

DON'T BOTHER USING A SUITE AS MOST SUITES ARE DESIGNED TO PROCESS FULL BIT STREAM PHYSICAL "IMAGES", AND WHEN PROCESSING FULL PHYSICAL IMAGES WILL GENERALLY PASS THE TESTS.   THEREFOR THE TESTS ARE DESIGNED TO TEST THE SOFTWARE CAPABILITY AT THE FOLDER/FILE LEVEL, AND AS SUCH ASSUME YOU ARE PERFORMING THESE TESTS ON LIVE SUSPECT MACHINES WHICH NORMALLY WILL NOT ALLOW INSTALLATION OF SUITES.

AGAIN, IF YOU TEST PROGRAMS/SUITES THAT CAN PERFORM A FULL BIT IMAGE, A LOGICAL DRIVE IMAGE, AND/OR A TREE/PATH/FOLDER FILE PROCESS, IN ORDER FOR THE TEST TO PROVIDE RESULTS SIMILAR TO STAND ALONE SOFTWARE YOU MUST ONLY RUN THE TEST USING THE TREE/PATH/FOLDER LEVEL PROCESSING ONLY OF FILES. THIS SETS UP THE SCENARIO CLOSEST TO MY TEST PARAMETERS WHICH YOU WOULD ENCOUNTER AT A SUSPECT LOCATION WHERE YOU "CANNOT" IMAGE AN ENTIRE PHYSICAL OR LOGICAL DRIVE BUT MUST PROCESS ONLY AT THE FILE/TREE/FOLDER LEVEL.

Also, regarding the processing of the test files by suites. Remember, we are testing, hash, copy, zip/unzip/restore. Most suites will be able to perform these tests. For instance: If you think about the suite process of finding a suspect file on a suspect drive, copying it or saving it to a forensic drive for transport from the original source to your analysis location, then restoring it at your analysis location, isn't that technically copying the suspect file from point A (suspect) to point B (analysis/evidence location). So suites do copy, as some, also perform a source zip, and destination unzip. They may not call it that, but the process and effect is the same. So use a suite if you wish, just operate ONLY at the folder/file level. No physical bit/sector analysis allowed for these tests.

And finally: when you are in a situtation, whether at a suspect/client or on your own machine there will be times when you will be required to merely hash individual files from the source and not have a suite available. Either hashing some single piece of evidence on the suspect system, or merely hashing your evidence zip file/container which will be placed in storage. In these and many other forensic/evidentiary situations you will not be able to use your suite, which means you must hash using a reliable hashing stand alone. So you better have one available that doesn't need installation.


TOP  

Some preliminary information: I want to remind that all the testing I have done and reference in this and any other testing related article was done using Windows on an NTFS file system on a desktop computer. The NTFS file system was used as the test environment because I believe that a significant number of corporations and other forensic investigations take place using the NTFS file system. Also, the test environment regarding ability to alter a files last access date, use long filenames and alternate data streams adds to the forensic and evidentiary complexity.

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.

A challenge   (6/2020) for you to test your forensic hash/copy/zip software for forensic and evidentiary reliability.

Back up to stats. TOP  

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.

In all the scenarios described here for the "copy" of data, we will assume the evidence to copy is from the original location, ie: the suspect source/evidence hard drive it is located on to an intermediate storage/transfer drive which will then be copied to an evidence analysis station OR a final resting place, say the permanent evidence storage.

For the sake of this discussion, lets agree on one thing regarding the "copying" of evidence from source to ultimate destination for analysis or review:
So define forensic copy in your own mind.

   SOURCE             Intermediate Step                           Destination
 original tree |  direct copy, no intermediate container  |   hard drive folder for analysis or preservation
 original tree |  forensic "imager" image container       |   extract to restore original structure for analysis etc.
 original tree |  zip/compress/container                  |   unzip to restore original tree structure for analysis etc.
 original tree |  create "container" of original evidence |   work directly within the container.

You may also want to consider some of the following situations, which may or may not be under your control due to corporate regulations, or legal retrictions (ie: targeted search warrant), and whether you will be using an installed program/suite or using a stand alone that is totally portable .

1. You are at suspects office and have to copy selected files/tree from suspect drive to your evidence drive.
    You CANNOT create an "image" of the drive. Must work off of originals in initial evidence gathering, or copy from the source server tree.

2. You have an obtained image at your office which is "mounted" to copy files out of the mounted image to your work drive.

3. You have an image and want to copy files directly from image, without mounting the image. Must use some sort of suite.

4. You have evidence files on your work computer, need to copy selected evidence files to a thumb for delivery to opposition.


In these instances of "copying", assume that you are called into a corporate environment where the suspect data belongs to a single individual who has a directory (that's a folder for you millennials) located on a large server. Then, assuming that the corporate practice (and possibly the search warrant) will ONLY allow you to copy/image those files belonging to the suspect.

What you now must decide, is how and what software you will use to capture (forensically copy) only that directory (or maybe just specific files) belonging to the suspect. If you think about the process, any "copy" program technically should be able to acquire the data from source, and then restore the structure of the data to a destination. There are a few different methods to accomplish the "copying" of evidentiary data files from the source to your work destination. And finally, and this is the important assumption for the "copy" requirement is to assume in this case the term copy means simply the acquisition of files from one location and ultimately placed in a second destination for analysis without any alteration of tree structure or other meta-data. This ultimate destination might also be for a legal reviewer of the evidence.


First copy consideration might be the use of an "imaging" program to create an "image" of suspect data as described here. For this process the general term used by the imaging software would be the term: "LOGICAL FOLDER IMAGE", meaning copy ONLY the logical file structure. This is a very important "imaging" term to remember for these tests.

Technically a copy process. Imager programs have the ability to "image" an entire physical drive (which in this case you are not allowed to do), and/or they can "image" or for this discussion, "copy" the entire suspect folder. SO: for this discussion, use of an "imager" program will be only for its ability to copy directory structures to an image file, and then restore the contents of that image file to a destination work location of your choosing, OR: without the intermediate "image creation" step, copy the entire source tree structure to your destination device/drive in an identical tree structure. This is the copy process of an "imaging" program. Testing of the capability and forensic soundness of the simple "copy" process performed by these imaging programs should be included in your tests, as they may not be all they are cracked up to be. But don't believe me, test it for yourself, and you will find faults, what a novel idea.

The second version of the forensic copy is to use only a program designed to copy the evidence and not create any intermediate "image" file of the evidence. This version of the forensic copy is claimed by any number of "forensically sound" (ha ha) copy programs. These are the stand alone programs which you should test. They come in both GUI and Command line, installable and stand alone. Over 90% of this type of program which I tested failed one or more of my test requirements outlined below. If your tests are designed to stress both the "imager" and the stand alone copy program you will be surprised.

And third is the tried and true method of zipping/packing/compressing/containerizing (use whatever term you are comfortable with) the suspect/source tree structure to a compressed file for transit. Then unzipping the zipped file at the examination destination for analysis. Sounds like an "imager" process to me. This "zipping" of the source evidence is considered copying in this case only because it can take a source tree, produce an intermediate file, and ultimately/hopefully unpack the tree in a location you chose for the examination of the evidence. This procedure is also used extensively when saving the evidence for posterity (thats long term retention, not your rear end) and/or making the evidence available for delivery to a final reviewer. In either case the original data must be saved and unpacked in its original form. Unpacking the evidence to your destination with the entire original file structure in tact. Good luck.

Now, you have options for creating your "copied" evidence. One is to use the imager to "image/restore/copy" the original evidence to your work drive, and second to find a reliable true forensically sound stand alone "copy" program, and third is to obtain a good zip/compressing program which will unzip the data as original. Once you have assured the forensic "copy" of the evidence you can begin the analysis of the case. BUT... do you have a good copy?.


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. (yes I said personnel, not human resources). 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.

TOP  

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.

Regarding "installed" forensic software, I was just testing another piece of software that required intallation. Luckily it was on my own machine. But think about this regarding any piece of software that is tied to your machine via some sort of license status. If you are using the software on your machine, fine and dandy. But what if you had to go to the client/suspect and do initial analysis on their hardware because, for whatever reason, you have to perform some analysis on site. (it has happened to me). Also, on site, you have to possibly perform some sort of initial hashing, or file inventory, or initial copy files off the suspect machine while at the remote site. If your forensic program is licensed and installed on your office machine, what/how do you plan to perform the necessary process at this remote location? Your license package is back at the office and you can't copy it to a storage medium and take it to any offsite investigation.

So be ready with a piece of software that is "portable" so you can take it to the field. This process of possibly having to do some basic analysis on site should cause you to think about what software you would use in an off-site initial analysis.

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/evidence 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?

Another item I consider, is using a program that can be scripted (or for you old folks, put in a batch file). This way, if your program or process needs additional options or parameters being set, you will always have a default setting to use. Which makes your process consistant and hopefully defensible.

Mr. Investigator, why did you use these options on my clients machine, and not on this other persons machine? How would you answer that? Your answer might be: I always use the same basic setup, so if i'm doing it wrong, at least I'm consistent. (That's a joke).


Copy Considerations

MULL THIS OVER:, or just think about it.

Recently there was a thread on a list that the persons were talking about making a copy from an NTFS drive to an exFat drive. In the case at hand, the file system difference didn't create much of a problem because they were copying a dd image to the exFat drive. But think about this. What is the forensicator was sitting at a suspect machine where he wasn't allowed to make a bit image, and could only copy the tree. And what if the media that the data was being copied to was exFat formatted? Now this leads me to two thoughts. (I know, thinking is bad).

First: The tree being copied has files with path lengths greater than 255 (>255) characters. This is normal on NTFS. However on exFat the limit is 255. So during the tree copy, might some long filename evidence be missed????
Second: Some of the evidence files located in the evidence tree structure might contain alternate data streams which could hold the evidence that could prove your case. Well, problem number 2. ExFat doesn't have alternate data streams. So a copy from NTFS to exFat might conceivably loose any and all alternate data stream evidence. A defence attorney argument panacea. (i think i spelled that correctly).
So: just think about the file systems you are copying from and to. No matter which way you go.


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
A sample of browser download alternate data streams. Interesting that the source is identified in real browsers:

two Firefox examples:
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://www.dmares.com/maresware/graphics/huskie19.jpg
HostUrl=https://www.dmares.com/maresware/graphics/huskie19.jpg

From NIST
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl/nsrl-download/current-rds
HostUrl=https://s3.amazonaws.com/rds.nsrl.nist.gov/RDS/current/RDS_modern.iso

from microsoft edge browser
"ms_edge.jpg[Zone.Identifier]"
[ZoneTransfer]
ZoneId=3
ReferrerUrl=http://www.dmares.com/
HostUrl=http://www.dmares.com/maresware/graphics/flag_sml.jpg

from the brave browser
"brave_image.jpg[Zone.Identifier]"
[ZoneTransfer]
ZoneId=3
HostUrl=about:internet


"chrome_image.jpg[Zone.Identifier]" (from WIN7)
[ZoneTransfer]
ZoneId=3

"opera_image.jpg[Zone.Identifier]" (from WIN7)
[ZoneTransfer]
ZoneId=3

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!

TOP  

MAJOR LAST ACCESS DISCUSSION and DISSAGREEMENT

You will see that one of the test parameters is the ability of the copy process to retain the files last access date on the original source medium, location/file. There are differing views on the importance of maintaining the last access date ON the source file. If you don't care about maintaining the original date, ignore that test parameter. Plain and simple, and jump to the next section.

First are those that say it is not of any import and can be ignored because most systems have it turned off. But for what reason is it turned off. There are a number of arguments that are used to justify: 1: not turning on last access update, and 2: ignoring its possible evidentiary uses.

Said another way, no one turned it on because no one has discussed possible evidentiary use of it. Because the IT people say that maintaining last access date is time consuming (and oh, by the way, I have a bridge in Brooklyn for sale). And you can probably think of a few more reasons for not having last update turned on. And, at the time of data/evidence acquition the investigator captured the files original last access, so no big deal if the original is modified. It may also be ignored because after the copy, the destination (hopefully) now maintains the original last access date on the copy. But WHO is maintaining the valid copy?

Is anyone really concerned with the accuracy of the files last access date? Maybe a knowledgable defense attorney is.

Now, why turn it on, and cause it to be maintained both on the ORIGINAL medium and in the copy? For at least one importanat reason: DO NOT ALTER EVIDENCE! Could the access date be important to your case. I have been involved with theft of secrets analysis where looking at the source last access date could provide some indication of the date of copying, printing, exfiltration, etc. If that last access was not available, the investigation might have a harder time proving when the particular action occured.

Now, you are the first investigator to make a copy of the data. Your copy process allows last access on the source medium to be altered to the time of your copy. Other (possibly opposition) investigators come in after you. Makes their own copy and lo and behold, on all the additional copies, one after the other, all have differing original last access dates recorded. All the "original" copies record different last access dates. Whose/what version do you rely upon.

Or suppose that some time in the future, when the original file dates are examined, for whatever reason, that access date comes into play. If it was allowed to be altered in the past, who/how/why was that done? And how many original "copies" made at different times may record differing last access dates?

I don't want to argue any further. Just saying, if it could be an item of contention in any future analysis/investigation/testimony, why not preserve the date on the source drive so future analysts working on the original medium can see the correct value. TOP  


Quick jump to the STATistics  testing results section of this article.

Before we end this discussion on forensic file copying, lets bring up one other idea. After you copy the evidence to a safe location, in some instances you may wish to uniquely identify the files. This means possibly renaming the files with unique names so that two files of the same name located in different directories will not be misinterpreted.

D:\Folder1\Folder2\evidence.docx
D:\Folder1\evidence.docx

Notice two files of the same name, but different locations. They may in fact be identicle, or different content but named the same.
You obtain evidence from D:\Folder1\Folder2\evidence.docx and use it in your report. But the report states evidence.docx as the source. For whatever reason, you didn't include the full path. So someone looking at your entire file structure may review the wrong evidence.docx file.
To eliminate any misinterpretation of which file you are talking about, why not rename the file with a unique bates number. Attorneys love bates numbering documents, so why not bates number the filename for uniqueness evidence.BATES001.docx. Enough said here. Find out more about bates numbering of filenames here.

TOP  

CLOUDY WITH A CHANCE OF EVIDENCE
GET YOUR HEAD OUT OF THE CLOUDS
ITS CLOUDING YOUR JUDGMENT

Enough pun for now

Before we start. An explanation. This section DOES NOT deal with cloud artifacts that are found on a machine where the person has a cloud account. Those artifacts are clearly defined and explained in any number of other online articles. And as for the google cloud account on a users machine, the artifacts of the "USERS" account activity may often be found in:
C:\Users\username\AppData\Local\Google\Drive
This section of the article doesn't really address that aspect. What I was attempting to do here, is see what "artifacts" or possible evidentiary data is left or available when a NON cloud user in some fashion downloads a file from the cloud. This downloaded file comes as someone sent/provided the user with a link to download the file. The user DOES NOT have his/her own cloud account. Assume one of two scenarious, as described below:
1. The prosecuting attorney requests the investigator provide the evidence, and the investigator provides the attorney a link to the cloud account from which the attorney downloads the evidence file(s). and/or
2. The investigation examines the computer of a suspect who does not have his/her own cloud account, but may at some point have downloaded information (evidence) from another persons cloud account. Both of these scenarios take place where the recipient (attorney or suspect) DOES NOT have a personal cloud account, but is receiving the link via a third party. (clear as mud?)


Recently I conferred (you know, thats when two people discuss a subject) with a forensic investigator to see what happens to evidence when you store it in the cloud. I wanted to see exactly how cloud storage may affect the storing and retrieval of the evidence. This idea seems to fall right in line with the topic of this article of forensic copying evidence. After all, if you place evidence in the cloud, and then retreive it, isn't that a subtle way of copying the data?
OR:
If the suspect stores evidence or downloads evidence from the cloud, is there any data on the suspect computer that may help you determine its cloudy origin?

Before we get started, the cloud storage platform tested was Google Drive and Microsoft Edge as the primary retrieval platform. You may be using a different storage cloud, and/or different retrieval application. So why not test it for yourself? Weird idea, I know.

There were two different scenarious where I thought the cloud storage may come into effect. Neither one is based on the fact that the "user" has their own cloud account. Both of these scenarios assume the user DOES NOT have a cloud account, and is merely accepting a link to download data/files/evidence etc.


The first scenario was where the investigator had evidence for the case, and placed it in some sort of storage container. For simplicity, lets say that all the relavent evidence was placed into a zip file, or extractable exe file. All the evidence in this single container was then uploaded to the cloud storage for both safe keeping, and later retrieval. The date all this was done is for arguments sake, 2021-01-01. The container had that MAC date set, as its creation. Then the container was uploaded to the cloud and stayed there until the prosecuting attorney needed to see it. Lets say 2021-05-01. At that point the investigator provides the attorney the appropriate link to download the zip container. Simple: Yes/No?

However, what we found was that obviously when the container was downloaded to the attorney's computer the MAC date was 2021-05-01. To be expected. But the question I (and possibly a defense attorney) would ask is: What was the original date the container was created. By looking a the MAC dates created on the attorney download, he has no way of knowing the original date of the container. So, one thing we found was that in this instance, the MAC date of the downloaded container DOES NOT reflect the original creation date. A simple problem to correct, just ask the investigator when it was created. But that may be a question which needs answering. Why, when retrieving something from this cloud are the MAC dates not restored? A simple answer I'm not going to divulge now. Not really a problem, but a good question.


Now for the second situation, which may turn out to be more important in an investigation. We found that when the item was retreived from the cloud, Microsoft Edge created two alternate data streams. One seemed incosequentional. It contained a single word: "Anaheim". No other information was contained in this data stream. However, the 2nd data stream seemed to hold information which an investigator might find useful. Suppose you were looking at a suspect computer and knew that occassionally they stored information that might be evidence in the cloud. But you really didn't/couldn't find out which cloud storage was used. It might be nice to know which cloud storage account some of the evidence came from, in order that there might be more up there not on the computer. Well, the 2nd data stream seemed to hold some information regarding the cloud account, name, and other information which may be related to where the suspect was maintaining the cloud account. Wouldn't it be nice to know what/where the suspects other cloud retained evidence was stored. Yes/No? This is not to say that other cloud storage locations and/or other download web browsers will provide different information relating to where/when the information is stored. But during an investigation it might be nice to know if any, and how many other files have an ADS referencing a cloud drive download.

Here is a truncated version of the ADS created thru firefox. Some alteration done here to protect the innocent. I have no idea how to decode all of the other coding. Maybe some intelligent person can provide that information.
Let it be known, that I tried downloading the item using three different browsers: Firefox, Brave, and Edge. Each time as expected, (except for Brave, which didn't provide any significant info) the numeric data within the ADS was different. AND surprisingly, the apparent filename "doc-XYZ99-docs.googleuser.com/docs" was different in both cases (Firefox, Edge). Now, the question is: how/what/when is the HostUrl key generated and by who? Go figure.


FIREFOX
"CLOUD_TEST_FF.exe[Zone.Identifier]"
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://drive.google.com/
HostUrl=https: //doc-XYZ99-docs.googleuser.com/docs/secure/abcdefghijklmne999999a1ao11a9m1r/2xabcdefghijk12345udibcr1edc8lha/1623862725000/18136513538596763992/00358687783704980179Z/1lskkd1hh_ bHQkpxG5CBbcsSq3QVk6dMU?e=download&nonce=dxxx999n94cd8&user=1234567abcdxxx999xxxd&hash=o22a8763f8zoklvjiqgxyz99abcebhgj


BRAVE
"CLOUD_TEST_BRAVE.exe[Zone.Identifier]"
[ZoneTransfer]
ZoneId=3
HostUrl=about:internet


Both OPERA and Internet Explorer failed to create any useable ADS. see below, identicle for both:
INTERNET EXPLORER:
"CLOUD_TEST_IE.exe[Zone.Identifier]"
[ZoneTransfer]
ZoneId=3



OPERA
"CLOUD_TEST_OPERA.EXE[Zone.Identifier]"
[ZoneTransfer]
ZoneId=3

So quick and dirty summary of this single simple cloud storage (copy) test. When downloading data from the cloud, the original MAC dates are NOT maintained, and second: the alternate data streams of the downloaded file might contain some interesting source information as to what cloud storage account was used. Could be a source of evidence.

TOP  
END OF DISCUSSION


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. 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? Does it alter the access date when it performs the hash? 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\guess_which_copy_program.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:

TOP  

For those adventurous souls who wish to test their forensic suites or stand alone software I have created a number of test files contained in a rar-exe self extracting file, which can be downloaded here.

Test data  containing about 30 files, in a self extracting rar executable. Also, just a little insight: I tried extracting the files from the exe using two other popular zipping programs. One wouldn't even attempt to open/extract the files, while the other extracted all the files, but failed to reset last access date on some of the files. I'll let you figure out which zip programs failed. If I told you, that would spoil all your fun.

Or better yet, read the testing challenge   article which contains links to additional reference/test data and testing requirements for copying and hashing evidentiary data.

Both of these source items contain files with long filenames > 255 characters, and files which contain Alternate Data Streams, (ADS). You can download them. Then see if you can find all the evidenciary files contained within the ADS, LFN's. Hash the files for evidentiary integrity, copy the files to an analysis workstation, and ultimately zip/compress the files for posterity. Then see if your data retention and restoration performs accurately.

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


Have fun, and a safe healthy day of testing.

If you test your software against the suggested parameters please let me know the results so i can add to the list.
If you get the same results as I have, please advise also.
For questions or answers (no flames please) regarding the hashing software, the NIST data records on my site, work007 (at) dmares.com. TOP  

Before closing you might want to look at some of these articles:
Inventory/Catalog files  Creating an inventory of evidentiary files
Forensic Hashing  Article tests over 30 "forensic" hash programs.
ZIP-IT for forensic retention  Article test a few zipping programs and
ZIP_IT_TAKE2  More tests for your zipping capabilities.
MATCH FILE HASHES  Demonstrates hash matches using Maresware.
A HASH software buffet   How-to use Maresware hash software


I would appreciate any comment or input you have regarding this article. Thank you. dan at dmares dot com,