Hi,
Is there any way we can call the underlying file system driver (NTFS/FAT) to do some stuff directly? i.e. is there any way we can bypass all filter drivers and get task done by the FSD itself.
Thanks
Aditya
like if I send some ioctl from my user mode exe to my driver and use IoCallDriver to ask the respective driver to process the request.
Is there some flaw in doing it this way?
Thanks
Well there is the huge flaw that for instance if you have a file system
filter that encrypts, or redirects files, or does backups the state will be
really bad. Do you really want a file that is mostly encrypted but because
of your special IOCTL is corrupted with unencrypted data in the middle, do
you really want a directory with a file when the filter whould have put it
on another device or directory entirely, or do you want to be missing part
of a backup because you choose to bypass the filters?
Yes there are ways to do it, no you should not.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> like if I send some ioctl from my user mode exe to my driver and use
> IoCallDriver to ask the respective driver to process the request.
>
> Is there some flaw in doing it this way?
>
> Thanks
>
Thanks Don for the reply,
Actually we’ll be doing it for files which are actually rootkits, and that too if user asked to do so specifically. So i do not think there is no harm as we already know that a particular file is rootkit and is harmful for the system .(There is some stuff already written which is taking care of this identification).
What is your suggestion in this case?
Aditya
*So i do not think there is any harm
The problem is still trying to do it right. The most likely result unless
the user you intend is an expert of file systems is corruption and a crash.
Besides which this assumes that the rootkit acts as a filter driver, which
is not the way most of them do it, they hook in one of many ways, most of
which will still capture your requests.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@ntdev…
> Thanks Don for the reply,
>
> Actually we’ll be doing it for files which are actually rootkits, and that
> too if user asked to do so specifically. So i do not think there is no
> harm as we already know that a particular file is rootkit and is harmful
> for the system .(There is some stuff already written which is taking care
> of this identification).
>
> What is your suggestion in this case?
>
> Aditya
>
>>Besides which this assumes that the rootkit acts as a filter driver, which is not the way most of them do it, they hook in one of many ways, most of which will still capture your requests.
No, this is just one concern, we are already taken care of many others things. But the point here is if we identify a file as rootkit, we’ll try to delete it legally first, which may not success as the API is hooked or the SSDT is hooket or the rootkit is having a filter driver which is actually denying its deletion. So the purpose is to get rid of all such deletion denying techniques and achieve the desired result that too only on a user request.
>most of which will still capture your requests.
Can you please provide a scenario for this. Like an app/driver asking NTFS directly to delete a file and still someone intercepting that.
>The problem is still trying to do it right. The most likely result unless the user you intend is an expert of file systems is corruption and a crash.
Point taken, It will be great if you can give me some pointers to look upon for the approach and some hints that why it may BSODs or do some memory corruption
Thanks
Aditya
wrote in message news:xxxxx@ntdev…
>>>Besides which this assumes that the rootkit acts as a filter driver,
>>>which is not the way most of them do it, they hook in one of many ways,
>>>most of which will still capture your requests.
>
> No, this is just one concern, we are already taken care of many others
> things. But the point here is if we identify a file as rootkit, we’ll try
> to delete it legally first, which may not success as the API is hooked or
> the SSDT is hooket or the rootkit is having a filter driver which is
> actually denying its deletion. So the purpose is to get rid of all such
> deletion denying techniques and achieve the desired result that too only
> on a user request.
>
>>>most of which will still capture your requests.
>
> Can you please provide a scenario for this. Like an app/driver asking NTFS
> directly to delete a file and still someone intercepting that.
The common scenarios would be SSDT hooking will see the request and can mess
with it. The other common hooking is to replace the NTFS DriverObject
routine pointers with their own. Less common still but seen, is to hook
the actual NTFS code directly.
>>>The problem is still trying to do it right. The most likely result unless
>>>the user you intend is an expert of file systems is corruption and a
>>>crash.
>
> Point taken, It will be great if you can give me some pointers to look
> upon for the approach and some hints that why it may BSODs or do some
> memory corruption
>
It will lead to DISK CORRUPTION which is even worse. The bottom line is
unless you know what every filter is doing, there is no way to protect
against this. As has been discussed many times before on ths forum, once
you have a rootkit it is an escalating game, even if you can eliminate the
common (for instance SSDT hooking) they can just move to a lower layer.
Blocking any access or faking it elsewhere to a given file is pretty easy
for a root kit.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
On Wed, Dec 10, 2008 at 7:18 PM, Don Burn wrote:
>
> wrote in message news:xxxxx@ntdev…
> >>>Besides which this assumes that the rootkit acts as a filter driver,
> >>>which is not the way most of them do it, they hook in one of many ways,
> >>>most of which will still capture your requests.
> >
> > No, this is just one concern, we are already taken care of many others
> > things. But the point here is if we identify a file as rootkit, we’ll try
> > to delete it legally first, which may not success as the API is hooked or
> > the SSDT is hooket or the rootkit is having a filter driver which is
> > actually denying its deletion. So the purpose is to get rid of all such
> > deletion denying techniques and achieve the desired result that too only
> > on a user request.
> >
> >>>most of which will still capture your requests.
> >
> > Can you please provide a scenario for this. Like an app/driver asking
> NTFS
> > directly to delete a file and still someone intercepting that.
>
> The common scenarios would be SSDT hooking will see the request and can
> mess
> with it. The other common hooking is to replace the NTFS DriverObject
> routine pointers with their own. Less common still but seen, is to hook
> the actual NTFS code directly.
Some more are hooking IoCompletion routines of IRPs.
>
>
> >>>The problem is still trying to do it right. The most likely result
> unless
> >>>the user you intend is an expert of file systems is corruption and a
> >>>crash.
> >
> > Point taken, It will be great if you can give me some pointers to look
> > upon for the approach and some hints that why it may BSODs or do some
> > memory corruption
> >
> It will lead to DISK CORRUPTION which is even worse. The bottom line is
> unless you know what every filter is doing, there is no way to protect
> against this. As has been discussed many times before on ths forum, once
> you have a rootkit it is an escalating game, even if you can eliminate the
> common (for instance SSDT hooking) they can just move to a lower layer.
> Blocking any access or faking it elsewhere to a given file is pretty easy
> for a root kit.
>
I would also like to back Don.
Because me myself has seen certain cases with user where his disk was
corrupted becoz anti malware s/w used deletion of files through above
mentioned mechanisms and his quotes were “I was not happy with these
rootkits but your s/w made it worse for me, my disk and data are corrupted
now”.
In cases where root kit is sitting so below that it is difficult to
catch/erase him legally, it’s better to provide a rescue bootable disk (or
disk image which user can write into USB/CD) with minium filesystem
(FAT/NTFS) read/write support.
Provide a utility with this bootable image which will remove the all the
malware entries.
Cheers
Deepak
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
xxxxx@gmail.com wrote:
No, this is just one concern, we are already taken care of many others things. But the point here is if we identify a file as rootkit, we’ll try to delete it legally first, which may not success as the API is hooked or the SSDT is hooket or the rootkit is having a filter driver which is actually denying its deletion. So the purpose is to get rid of all such deletion denying techniques and achieve the desired result that too only on a user request.
Let me add two points to the excellent advice Don has already given.
- Users, with *very* few exceptions, are not nearly smart enough to
know whether they should OK an action like the one you are suggesting.
They won’t understand the implications, and after their disk is ruined,
they aren’t going to accept the explanation that “well, you told the app
it was OK to do this.”
One half of our company does outsourced IT support for small
businesses. We get infected machines in here every week. If we can’t
find a solution in 15 minutes, then we back up the data files, reformat,
and reinstall. That is ALWAYS a more efficient tactic than trying to
undo the malware by hand. And let me tell you, there are plenty of
people here who would like to have 15 minutes alone in a room with the
folks who write this crap.
- The people who write rootkits are smarter than you. Whatever
counter technique you come up with, they have already anticipated it,
and have code in place to subvert it. You cannot win. It’s just a
fact. The best we can do is detection and warning.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank Don, Tim, and NTDEV for all the help and prompt suggestions.
Aditya