Skip to content

Safe processes are not detected like expected #55

@olljanat

Description

@olljanat

Thanks for publishing digitally signed version of minifilter driver while keeping its code in open source.

However, I noticed that you have same bug which exists even original code RansomWatch that this function is not valid way to detect device path to Windows folder at least with all the possible configurations:

// sets the system root path, received from user mode application, we copy the systemRootPath sent on the message
VOID setSystemRootPath(PWCHAR setsystemRootPath) {
RtlZeroBytes(systemRootPath, MAX_FILE_NAME_SIZE);
RtlCopyBytes(systemRootPath, setsystemRootPath, MAX_FILE_NAME_LENGTH);
RtlCopyBytes(
systemRootPath + wcsnlen(systemRootPath, MAX_FILE_NAME_LENGTH / 2),
L"\\Windows",
wcsnlen(L"\\Windows", MAX_FILE_NAME_LENGTH / 2));
DbgPrint("Set system root path %ls\n", systemRootPath);
}

This is what I see on debug logging:

FSFIlter: Entered FSInstanceSetup
loaded scanner successfully!!! user connected, port=0xFFFFB60D816F6310
Set system root path \Device\harddiskVolume\Win

And what I don't see are !!! FSFilter: Open Process not recorded, both parent and process are safe messages.

Tested with v1.1.0 on Windows 10, version 1809 (which basically same than Windows Server 2019) with both UEFI and non-UEFI installation and behavior is same on both of them.

I also tested that if I hardcode system root path to \Device\HarddiskVolume3\Windows then on my UEFI setup then safe processes are detected like expected.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions