AV knows what I do even when I access underlying NTFS directly.

OSR_Community_User · January 12, 2006, 12:04am

Hi All,

I’ve got an interesting but annoying situation. I’ve got a direct file
system access kernel driver (not filter driver).
What it does is simply create its own IRP(roll my own IRP) to access
files(SetInformationFile, QueryInformationFile, and QueryDirectory) with
underlying NTFS driver’s volume device object(VDO). I open the file using
IoCreateFileSpecifyDeviceObjectHint with retrieved NTFS VDO to bypass
filters. It seemed working fine till I found FileMon and FileSpy both
reported strange results when running with Norton AV and Sophos AV filters.

I issue IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY, and they report
IRP_MJ_CREATE, IRP_MJ_READ, FASTIO_QUERY_BASIC_INFO, etc. And I also found
when i issueed my IRP, NtCreateFile and NtCreateSection were also invoked. I
narrowed down the test scenario, but there were still a bunch of Major IRPs
and FASTIOs. Using IrpTracker, I found norton antivirus is involved with
this IRP flows. In conclusion, both AV service process in the background and
the original user process accessing files participated in sending these IRPs
to get the file information and scan the file.

My question is, ‘How does norton AV(as well as Sophos AV) filter driver know
what I’m doing?’.
Interestingly enough, neither IoCreateFileSpecifyDeviceObjectHint() nor
ZwClose() triggered any AV IRP activities. It obviously happens for
IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY. Remember this IRP is not
caught by FileMon and FileSpy. This just create another IRP dispatches by AV
because AV detects my attempt to enumerate the directory. The only
possibility they could detect my file access may be through IrpCompletion
routine. Because IrpCompletion routines are invoked for every filter
drivers, AV filter drivers would have seen my IRP’s existence even though
they couldn’t see it in IRP population stage along the filter stack.

Is my analysis plausible? If so, can someone tell me how to avoid using
completion routine in my driver? Or any other thoughts? I have to avoid
unnecessary interference with AVs for performance reasons.

Many thanks.

Kind Regards,
Sean

OSR_Community_User · January 12, 2006, 12:22am

Oh my source code might be useful to find the problem.

NTSTATUS CDirectFile::QueryDirectoryFile(
HANDLE hFile,
FILE_INFORMATION_CLASS FileInformationClass,
PVOID Information,
ULONG InformationSize,
BOOLEAN RestartScan,
BOOLEAN ReturnSingleEntry
)
{
NTSTATUS status;
PIRP irp;
KEVENT event;
IO_STATUS_BLOCK iostatus;

if(IsWinXP())
{
//
// Get the File Object pointer from File Handle
//
PFILE_OBJECT FileObject;
status = ObReferenceObjectByHandle(
hFile,
FILE_READ_ACCESS,
*IoFileObjectType,
KernelMode,
(PVOID*)&FileObject,
0
);

if(!NT_SUCCESS(status))
return status;

// We got FileObject from hFile, so dereference it.
ObDereferenceObject(FileObject);

// Set up Base FS Device Object
// pBaseFsDeviceObject is initialized to underlying base
file
// system VDO through constructor. If it isn’t set, find
it out
// manually. (This class isn’t for remote file system,
// so Vpb is valid)
if(m_pBaseFsDeviceObject == NULL)
{
if(FileObject->DeviceObject->Vpb == NULL)
return STATUS_ACCESS_VIOLATION;

m_pBaseFsDeviceObject =
FileObject->DeviceObject->Vpb->DeviceObject;
}

// Allocate an irp for this request. This could also
come from a
// private pool, for instance.
irp = IoAllocateIrp(m_pBaseFsDeviceObject->StackSize,
FALSE);
if(!irp)
{
return STATUS_INSUFFICIENT_RESOURCES;
}

irp->UserBuffer = Information;
irp->UserEvent = &event;
irp->UserIosb = &iostatus;
irp->Tail.Overlay.Thread = PsGetCurrentThread();
irp->Tail.Overlay.OriginalFileObject = FileObject;
irp->RequestorMode = KernelMode;

// Initialize the event
KeInitializeEvent(&event, SynchronizationEvent, FALSE);

//
// Set up the I/O stack location.
//
PIO_STACK_LOCATION irpSp =
IoGetNextIrpStackLocation(irp);

irpSp->MajorFunction = IRP_MJ_DIRECTORY_CONTROL;
irpSp->MinorFunction = IRP_MN_QUERY_DIRECTORY;
irpSp->DeviceObject = m_pBaseFsDeviceObject;
irpSp->FileObject = FileObject;
irpSp->Parameters.QueryDirectory.FileInformationClass =
FileInformationClass;
irpSp->Parameters.QueryDirectory.Length =
InformationSize;

irpSp->Flags |= ReturnSingleEntry ?
SL_RETURN_SINGLE_ENTRY : 0;
irpSp->Flags |= RestartScan ? SL_RESTART_SCAN : 0;

//
// Set the completion routine.
//
IoSetCompletionRoutine(irp, LinkTo(IrpComplete), this,
TRUE, TRUE, TRUE);

//
// Send it to the FSD
//
IoCallDriver(m_pBaseFsDeviceObject, irp);

//
// Wait for the I/O
//
KeWaitForSingleObject(&event, Executive, KernelMode,
TRUE, 0);

status = iostatus.Status;
}
}

NTSTATUS CDirectFile::IrpComplete(
PDEVICE_OBJECT DeviceObject,
PIRP Irp,
PVOID Context
)
{
// Copy the status information back to IOSB.
*Irp->UserIosb = Irp->IoStatus;

// Set the user event - wakes up the mainline code doing this.
KeSetEvent(Irp->UserEvent, 0, FALSE);

// Free the IRP now that we are done with it.
IoFreeIrp(Irp);

return STATUS_MORE_PROCESSING_REQUIRED;
}

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sean Park
Sent: Thursday, 12 January 2006 4:04 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] AV knows what I do even when I access underlying NTFS
directly.

Hi All,

I’ve got an interesting but annoying situation. I’ve got a direct file
system access kernel driver (not filter driver).
What it does is simply create its own IRP(roll my own IRP) to access
files(SetInformationFile, QueryInformationFile, and QueryDirectory) with

underlying NTFS driver’s volume device object(VDO). I open the file
using
IoCreateFileSpecifyDeviceObjectHint with retrieved NTFS VDO to bypass
filters. It seemed working fine till I found FileMon and FileSpy both
reported strange results when running with Norton AV and Sophos AV
filters.

I issue IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY, and they report

IRP_MJ_CREATE, IRP_MJ_READ, FASTIO_QUERY_BASIC_INFO, etc. And I also
found
when i issueed my IRP, NtCreateFile and NtCreateSection were also
invoked. I
narrowed down the test scenario, but there were still a bunch of Major
IRPs
and FASTIOs. Using IrpTracker, I found norton antivirus is involved with

this IRP flows. In conclusion, both AV service process in the background
and
the original user process accessing files participated in sending these
IRPs
to get the file information and scan the file.

My question is, ‘How does norton AV(as well as Sophos AV) filter driver
know
what I’m doing?’.
Interestingly enough, neither IoCreateFileSpecifyDeviceObjectHint() nor
ZwClose() triggered any AV IRP activities. It obviously happens for
IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY. Remember this IRP is
not
caught by FileMon and FileSpy. This just create another IRP dispatches
by AV
because AV detects my attempt to enumerate the directory. The only
possibility they could detect my file access may be through
IrpCompletion
routine. Because IrpCompletion routines are invoked for every filter
drivers, AV filter drivers would have seen my IRP’s existence even
though
they couldn’t see it in IRP population stage along the filter stack.

Is my analysis plausible? If so, can someone tell me how to avoid using
completion routine in my driver? Or any other thoughts? I have to avoid

unnecessary interference with AVs for performance reasons.

Many thanks.

Kind Regards,
Sean

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@pctools.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 12, 2006, 1:54am

Hmmm…

On second thought, I realized other intermediate AV filter drivers’ IRP
completion routines won’t be called because there is no
IRP_STACK_LOCATION for them in the IRP. There must be another reason…

They can’t back-trace for ZwClose(). However, IRP_MJ_CLEANUP and
IRP_MJ_CLOSE for this customized IRP won’t be directed to intermediate
filter drivers because it checks VPB of the FileObject and sends to the
correct VDO, which is underlying base file system VDO.

Any thoughts?
I appreciate any comments.

Cheers,

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sean Park
Sent: Thursday, 12 January 2006 4:22 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] AV knows what I do even when I access underlying
NTFS directly.