A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about kernel-mode development.
 #31350  by Li Yong
 Mon Mar 19, 2018 3:18 am
I'm able to remove files locked by a determinated process (opened handles). First i use KeStackAttachProcess, after it, all files of root folder and yours subfolders linked with this process are enumerated, when found yours handles, they are immediately closed and file can be deleted with success. But some files not can be deleted because exists a file system filter driver that is against exclusion.

There is some thing that i can make to also delete these files? I already saw some AK (anti rootkit) able to this.
 #31354  by Li Yong
 Mon Mar 19, 2018 11:18 pm
EP_X0FF wrote: Mon Mar 19, 2018 6:37 pm AFAIR KsBinSword do this and it is open source

viewtopic.php?p=4052#p4052
Thank you EP_X0FF. I saw KsBinSword source code.
Vrtule, based in my conclusion (and after see KsBinSword source code) your suggestion only will works with my own file system filter driver, but i'm searching also about how remove 3rd files. some AK's can remove file of 3rd that are protected by a file system filter driver for example PcHunter, if you use the option "Force Delete" of section "File" to remove a folder created by any antivirus software (knowing that antivirus softwares protect some of your file with a file system filter driver) for example, you will have success with remove.

But if true answer to what was asked on title of this question is a confidential info that no one can say, or even so no one have idea how works, i will respect.
 #31357  by Vrtule
 Thu Mar 22, 2018 7:32 am
Well, my suggestion is to communicate with the file system driver directly. For example, let's have a NTFS volume, then the device stack for its mounted file system would be
* <some devices or possibly nothing> - legacy file system filter drivers
* <unnamed device> (\FileSystem\FltMgr) - this device causes that all file system minifilter drivers registered for the instance are in effect
* <some devices> - possibly another set of legacy FSDs (although I think I have never seen them in this place)
* <unnamed device> (\FileSystem\Ntfs) - the file system at its beauty.

At normal circumstances, file operation requests go through all of these devices down and up the stack (from the top device to the lower one - the ntfs.sys one). My Suggestion is to send the request directly to that device of ntfs.sys, thus bypassing all upper devices (including all filters and minifilters).
 #31362  by Li Yong
 Thu Mar 22, 2018 1:18 pm
Vrtule wrote: Thu Mar 22, 2018 7:32 am Well, my suggestion is to communicate with the file system driver directly. For example, let's have a NTFS volume, then the device stack for its mounted file system would be
* <some devices or possibly nothing> - legacy file system filter drivers
* <unnamed device> (\FileSystem\FltMgr) - this device causes that all file system minifilter drivers registered for the instance are in effect
* <some devices> - possibly another set of legacy FSDs (although I think I have never seen them in this place)
* <unnamed device> (\FileSystem\Ntfs) - the file system at its beauty.

At normal circumstances, file operation requests go through all of these devices down and up the stack (from the top device to the lower one - the ntfs.sys one). My Suggestion is to send the request directly to that device of ntfs.sys, thus bypassing all upper devices (including all filters and minifilters).
How could be (in code) this request directly to that device of ntfs.sys? you say to send from usermode (DeviceIoControl) to kernel mode, right? and also already that we talking about send to thirdy's devices, i cannot "write a DeleteFile() function in these devices" :D, then how the file can be removed in this case? only with a simple msg sent :? ? i want that you explain better about this and give a work code example.

thanks in advance.
 #31363  by tangptr
 Thu Mar 22, 2018 8:43 pm
Well, you may analyze the file system by reading and writing disk directly. Writing disk sections via disk mini-port driver (scsi instructions) may penetrate disk recovery protection.
 #31368  by Vrtule
 Fri Mar 23, 2018 1:35 pm
How could be (in code) this request directly to that device of ntfs.sys? you say to send from usermode (DeviceIoControl) to kernel mode, right? and also already that we talking about send to thirdy's devices, i cannot "write a DeleteFile() function in these devices" :D, then how the file can be removed in this case? only with a simple msg sent :? ? i want that you explain better about this and give a work code example.

thanks in advance.
This cannot be done from usermode. You have to implement a kernel mode driver that finds the right device of the base file system (ntfs.sys for example), builds all necessary requests (IRPs) manually and sends them directly to that device.

You can of course use the raw disk approach suggested by tangptr. That can be done from usermode (but you need admistrative privileges anyway), howerver, it bypasses file systems and their caching mechanisms which is kinda dangerous (the changes you write directly to the disk can be invisible since the cache is not informed about them).