search

Invoke-IR / PowerForensics

PowerForensics provides an all in one platform for live disk forensic analysis
MIT License
1.38k stars 274 forks source link

Implement FSCTL_ENUM_USN_DATA #141

Closed tophf closed 7 years ago

tophf commented 8 years ago

Unlike currently implemented full enumeration of USN journal with records for all changes of a file/directory, FSCTL_ENUM_USN_DATA produces only one record that corresponds to actually existing file/directory, thus allowing a much faster processing of drive's actual directory structure than the standard Get-ChildItem enumeration.

jaredcatkinson commented 8 years ago

I'm not sure exactly where you'd like to see this implemented. Are you specifically talking about replacing the MFT parsing portion of Get-ForensicChildItem?

jaredcatkinson commented 8 years ago

One of the design philosophies that I'd like to stick to for PowerForensics is to limit the reliance on Windows API calls like DeviceIOControl. Currently, the main API that is relied upon is CreateFile which is necessary to get a handle to the Physical Drives or Logical Volumes.

jaredcatkinson commented 8 years ago

I do think the Get-ForensicChildItem code could be improved to leverage the B+ Tree structure of the INDEX_ALLOCATION attributes.

tophf commented 8 years ago

Well, my goal is to use the much faster USN journal instead of enumerating nested directories via normal methods. For example, to get a list of all files (recursively) under specific directory (possibly in a separate thread) so that it's possible to display a meaningful progress indicator while processing these files (copying/searching and so on).

jaredcatkinson commented 8 years ago

Might be worth checking out this module by Boe Prox https://github.com/proxb/PoshUSNJournal. He parses the UsnJrnl using the IOCTLs instead of doing the raw parsing like PowerForensics.

jaredcatkinson commented 8 years ago

I'm curious, the UsnJrnl typically doesn't have a reference to every file because it can only grow to a predetermined size before it starts overwriting older entries. Wouldn't this create holes in a directory listing that is based solely on it?

Or are you trying to supplement the MFT through the UsnJrnl somehow?

tophf commented 8 years ago

I haven't encountered holes (or haven't noticed them) while using this approach in a non-posh script, but I guess you're right, it's unreliable.