Keep Track of File Acquisition with ProcMon

This post was inspired by Lenny Zeltser's recent blogs about using NirSoft Utilities in malware analysis.

Have I said that guy rocks? If not, let it be said. He rocks.

In having to do acquisition of loose native files across clients' LANs and WANs, you come across some difficulties, and slow networks. And large files, like 18GB NSFs that you find out you're pulling across the WAN from Arizona to Michigan. What? Yeah, no one realized that a guy in Michigan had his NSF in Arizona. No wonder he was complaining about email being slow... :) Anyway, aside from that, I've come across lots of situations where a file copy seems to be hung, but you don't want to kill it and try to start over in case it's actually still doing something. The things you want to know in those scenarios are:
* Has the Source already been copied to the Destination
* Has the Source already been hashed
* Has the Destination already been hashed
* Is the process still running/active
* How much longer is it going to take

Even if you could safely preview your destination without risking changing timestamps or otherwise messing something up, it would still show the full file size, regardless of how much has been written, so that's no good. And for the hashing bit, how could you really tell?

Some applications will provide status/progress updates. For instance, Pinpoint Labs' Safecopy will show progress, and even provide an indication of where you are in the process, but it can't tell you if it's still working or not. PixeLabs' XXCopy can provide a progress bar (and used with Jesse Kornblum's md5deep for hashing, which can also provide a progress report), Dan Mares' upcopy (my personal favorite) provides periodic updates, but none of these (or robocopy, RichCopy, etc) are able to tell you what you're actually dealing with. Enter SysInternals' Process Monitor, aka procmon.

You have to know how your tool operates, but if you do, procmon can be extremely helpful for discerning if you're still good to go, where you are in the process, and how much longer you can anticipate it taking (you'll have to do your own math). For my example I'm using upcopy, and copying several 10GB files.

upcopy command

Upcopy works by reading and writing the source to the destination. It then hashes the source, followed by the destination. At that point, it's done. Most apps work in pretty much the same way, but you have to know yours in order to make the best use of procmon.

Naturally, there will be a lot of activity in procmon, so we have to find our executable and set a filter to show only that. Click the binocular icon or CTRL-F to open the search feature. You can also just scroll down to find the exe you're looking for, as the search feature will give you every instance of it, which could give you results from antivirus scanning it, HIPS checking it, parent process, etc. Might take longer than what it's worth that way! If you're not sure the actual EXE name, find it first in SysInternals' Process Explorer.

Process Explorer

procmon, "find"

Once you locate your executable, right-click and select "include..."

procmon, "include exe"

By default, procmon show the most recent activity at the bottom, so you'll need to scroll down. I don't tend to change the configuration, sorting, etc once it's running, as it does use resources. Be aware and judicious in your choices.

The first set of screenshots here show the copy process, from source (F:) to destination (V:) (yes, I'm actually going local to network, the opposite of what we'd typically be doing in a collection; I needed to back up some files to my NAS anyway). You can see the "Offset" in the far right column increasing; this correlates to the file-size, and is one piece in checking progress.

copy progress

more copy progress

Once the copy process is complete, you'll see the activity in the next screenshot. Note the "ReadFile," "END OF FILE" and the "Offset" showing the total file size in bytes (yep it's a 10GB file), followed by the file being closed on source and destination. Then the hashing of the source will commence.

copy complete

You can follow the progress through hashing the same way. All the entries will show "ReadFile" action on the source, and you can keep tabs via the "Offset" value increasing. Note that by doing some math here (change in size over time passed), you can determine an approximate timeframe for completion of that portion.

hashing source

more hashing source

and yet more hashing source

Once it's finished hashing the source, you'll see the following. Just as before, note the "ReadFile," "END OF FILE" and the "Offset" showing the total file size, followed by the file being Closed. Then the process repeats for the destination.

source hash complete

Here's the destination hashing in progress; same as for the source, only the location is changed.

hashing destination

And, just as before, when the destination is finished hashing, you'll see it clearly in the activity in procmon. There's one other item to note here, though, and that is the logfile activity for the hash data.

destination hash complete

Lather, rinse, repeat, and that's about it. Do be aware that running procmon can consume system resources you might otherwise need (it lives off RAM). That's one of the reasons I like upcopy; it's no resource hog at all. And it's freakin' fast. I know Dan Mares thinks people don't use CLI anymore, but I beg to differ!

No great revelation of forensic truth here, just a little something to keep you in the know on what's happening with a file copy. Could also be applied to other processes where data is being written out and taking a long time, or when you need to more accurately calculate time estimates for the same (for some reason those application/system progress reports don't seem to be very accurate). I've found it useful; I hope others do as well.

Happy forensicating!