Capture `NtFsControlFile` syscall as a new `FsControlFile` event type

[rabbitstack]

LoMotivation

Fibratus doesn't currently surface NtFsControlFile calls, which are used to send device I/O control (IOCTL) codes to file system drivers/devices. This syscall is of interest for detecting abuse of raw disk access, filter driver manipulation, reparse point/symlink tricks, and other low-level filesystem interactions that bypass normal file I/O APIs.

Expectation

Fibratus gains a new FsControlFile event type that captures NtFsControlFile invocations, including the IOCTL code being issued.

Proposal

• Capture the NtFsControlFile syscall and emit it as a new FsControlFile event type. This syscall is emitted by the NT Kernel Logger provider with opcode 75.
• Reuse the existing binary layout already used for SetFileInformation/RenameFile events, since FsControlFile shares the same underlying structure
• The key difference is semantic: the info-class parameter in this shared layout represents the IOCTL code for FsControlFile, rather than a file information class. The IOCTL code should be decoded per the standard Windows IOCTL bit layout:

  31                16 15 14 13     2  1   0
  +------------------+-----+---------+-----+
  | DeviceType    |Access| Function |Method|
  +------------------+-----+---------+-----+
       16 bits          2      12 bits   2 bits

• DeviceType (bits 31–16): identifies the device/driver type the IOCTL targets
• Access (bits 15–14): required access rights (read/write/either)
• Function (bits 13–2): the driver-specific function code
• Method (bits 1–0): the buffering method (buffered, direct in/out, neither)

Decode these four sub-fields from the raw IOCTL code, so filter rules can match on DeviceType/Function individually rather than only the raw numeric code.

Additional context

• Since the binary layout is shared with SetFileInformation/RenameFile, this should slot into the existing ParamDecoder path for that layout rather than requiring a new decoder. The differentiator is purely in how the info-class field is interpreted and exposed to filters
• Well-known IOCTL codes (e.g. those tied to FSCTL_SET_REPARSE_POINT, raw volume access, or filter communication ports) are likely good candidates to expose as named constants for rule authors, rather than requiring raw numeric matching
• Worth checking whether DeviceType/Method/Access decomposition is exposed as separate filterable fields (e.g. file.fsctl.device_type, file.fsctl.method) or bundled into one enriched field. Separate fields would make sequence/detection rules easier to write