First authored Feb. 2019. Long time ago by computer standards.
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.

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

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.

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

First is 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 conplete 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.

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?
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.

PIECE_OF_TAIL.mp4     72,788,245  01/29/2022 08:19:20:653w

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

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

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

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_12(2023)
    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.

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.

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.

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.

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.

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.

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.

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.

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).

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|

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.

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

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.

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:

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,