DFIR Patterns

[F01TECH]

Modified versions of /fs/ for semi-automated parsing of Disks/Volumes/Filesystems related to digital forensics and reporting.

[WerWolv]

Wow that's some very impressive work, thank you very much!

Since this is for disk images, I doubt we'll be able to have a proper test file for them so that part is okay. Could you add the folder to the table in the readme page though please?

[F01TECH]

Great, thanks!

These good?

| DISK_PARSER (DFIR) | application/x-ima | 'patterns/DFIR/DISK_PARSER.hexpat' | Recursive Disk/Volume/Filesystem parsing |

| EXFAT (DFIR) | | 'patterns/DFIR/exFAT.hexpat' | Imported by DISK_PARSER.hexpat |

| FAT32 (DFIR) | | 'patterns/DFIR/FAT32.hexpat' | Imported by DISK_PARSER.hexpat |

| NTFS (DFIR) | | 'patterns/DFIR/NTFS.hexpat' | Imported by DISK_PARSER.hexpat |

[WerWolv]

Are the patterns meant to be used on their own as well? If not, I'd suggest only adding the main pattern that people are meant to import.
Besides that, about the name. Pretty much all other patterns are named after the thing they're parsing so DFIR is a bit out-of-line I guess since it more describes its purpose than the data format it's parsing. Not sure if we should make an exception here since there's already are patterns available that are specifically for parsing some of these file systems

[F01TECH]

Good call.

In theory, the proposed patterns can replace the existing versions in /fs/. When I was first developing, I had kept them separated due to temporary hard coded placements and never circled back around to consider full replacement. The entry point placements are all 0x0, so will function as semi-automated or targeted (manual placement), just as the originals, but with all the enhancements.

Downside to full replacement:

• The parsing of the file record entries...
  1. Adds considerable evaluation time on large volumes. Under 5 seconds on 16GB or less, around 10-20 seconds on 100GB, and around 30-50 seconds on 500GB when capped at 4096 file record entries.
  2. If someone were to use without checking the notes for each pattern, they may think they've parsed all entries or the pattern is incomplete/broken/inaccurate...
  3. Overkill for someone that simply wants to parse the MBR/GPT and any VBRs without diving deeper into the file system.

I'll need to test and report back; Will setting the Root Dir/MFT MAX_NUM_ENTRIES to 0 break anything.

[F01TECH]

I attempted to add a 'if DEEP_DIVE' for a quick fix, but too many errors to contend with right now.

If someone doesn't want to parse FAT1/FAT2, RootDir, or MFT, to speed things up, they can simply comment out the related calls or if the pattern offers a 'max number of' constant, set to zero.

For FAT32.hexpat:

• // FAT_Entry FAT1[MAX_FAT_CHUNKS] @ FAT1_start_offset + 8;
• // FAT_Entry FAT2[MAX_FAT_CHUNKS] @ FAT2_start_offset + 8;
• // RootDirParser ROOT_DIR_ENTRIES[while(std::mem::read_unsigned($, 1) != 0x00)] @ root_dir_start;
• // INFO_Overlay SFN_CLUSTER_LIST[MAX_SFN_CLUSTER_RELATIONS] @ FAT1_start_offset [[name("SFN <-> CLUSTER (DERIVED)")]];

For exFAT.hexpat:

• const u64 MAX_FAT_CHUNKS = 0;
• const u64 MAX_DIR_ENTRIES = 0;

for NTFS.hexpat:

• // MFT_RECORD NEXT_RECORDS[while(fr_magic($) == NTFS_RECORD_TYPES::magic_FILE)] @ (nbs.mft_lcn * cluster_size + 12 * mft_rec_size) [[inline, static]];

That being said, its up to you whether or not we replace the simplicity/usability of the current /fs/ with the proposed patterns or keep it separate as /DFIR/...

If we keep it separate, I can remove the duplicated file system patterns from the table and just have a reference to DISK_PARSER.hexpat?