Hi All!
I have a driver which is diskdrive class upper filter.
Is there is a way of preventing other drivers to attach to \Device\PhysicalHardDisk0 and \DosDevices\PhysicalHardDisk0.
Thanks,
Igor.
What are you really trying to do? For instance do you mean you don’t want a
storage stack created over a given device? Are you trying to deny access to
the device, or what? Give us some idea of your real goal (not stop
attachment) and maybe we can give you an answer.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 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…
> Hi All!
>
> I have a driver which is diskdrive class upper filter.
>
> Is there is a way of preventing other drivers to attach to
> \Device\PhysicalHardDisk0 and \DosDevices\PhysicalHardDisk0.
>
>
> Thanks,
> Igor.
>
>
>
Sorry for being unclear.
I do not want any other driver to bypass our driver while RW to disk.
There are a virus which bypasses our driver , after short disassembly I found that they are attaching to device which we are filtering. And supposedly perform direct IO overwritng some of the system files.
The virus is new IGM “robot-dog” and driver it is using is pcihdd.sys.
Thanks,
Igor.
xxxxx@shaw.ca wrote:
Sorry for being unclear.
I do not want any other driver to bypass our driver while RW to disk.
There are a virus which bypasses our driver , after short disassembly I found that they are attaching to device which we are filtering. And supposedly perform direct IO overwritng some of the system files.
The virus is new IGM “robot-dog” and driver it is using is pcihdd.sys.
There is no solution to this. Whatever you do, they can undo, and in
the process of implementing it, you will unintentionally break some
useful scenario used by a legitimate driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Also, isn’t PCIHDD.sys part of the virus? If so, why are you even
bothering with this? Once the system is compromised, it all becomes a
waste of time until the system is clean.
mm
Tim Roberts wrote:
xxxxx@shaw.ca wrote:
> Sorry for being unclear.
> I do not want any other driver to bypass our driver while RW to disk.
> There are a virus which bypasses our driver , after short disassembly I found that they are attaching to device which we are filtering. And supposedly perform direct IO overwritng some of the system files.
> The virus is new IGM “robot-dog” and driver it is using is pcihdd.sys.
>There is no solution to this. Whatever you do, they can undo, and in
the process of implementing it, you will unintentionally break some
useful scenario used by a legitimate driver.
In addition, at least on the CD/DVD side of things, lots of crappy
products that aren’t intentionally viral know better than the OS and
happily bypass all lower filter drivers in order to send data directly
to the PDO.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Monday, November 26, 2007 2:55 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to not allow attach to lower device
Also, isn’t PCIHDD.sys part of the virus? If so, why are you even
bothering with this? Once the system is compromised, it all becomes a
waste of time until the system is clean.
mm
Tim Roberts wrote:
xxxxx@shaw.ca wrote:
> Sorry for being unclear.
> I do not want any other driver to bypass our driver while RW to disk.
> There are a virus which bypasses our driver , after short disassembly
I found that they are attaching to device which we are filtering. And
supposedly perform direct IO overwritng some of the system files.
> The virus is new IGM “robot-dog” and driver it is using is
pcihdd.sys.
>There is no solution to this. Whatever you do, they can undo, and in
the process of implementing it, you will unintentionally break some
useful scenario used by a legitimate driver.
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
Thanks for answers guys,
Tim Roberts wrote:
There is no solution to this. Whatever you do, they can undo, and in
the process of implementing it, you will unintentionally break some
useful scenario used by a legitimate driver.
Yes this is also my point of concern , possibility of breaking legimate driver. We have I would 20mil installation around the world and I have no idea what other third-party software might be used on all the systems.
MM wrote:
Re: How to not allow attach to lower device
Also, isn’t PCIHDD.sys part of the virus? If so, why are you even
bothering with this? Once the system is compromised, it all becomes a
waste of time until the system is clean.
pcihdd.sys indeed a part of the virus.
Our product is restart-and-restore product (Deep Freeze) and if after restart that crap is still there , it means we have failed, and I have to find a workaround anyhow.
Are you an antivirus product?
For all products except antivirus, it is a good idea to just fail any
guarantees on a virus-infected machine.
Also: if PCIHDD virus was caught during your “volatile” session, then
wouldn’t your rollback on reboot destroy this virus?
Prohibiting all disk filters is a bad idea. All companies whose products
require the disk filter would post the notice on their websites about “do not
use DeepFreeze - it violates the Microsoft-imposed rules and thus causing
interops with our product” or such.
So, the worst case for you is to cut away PCIHDD virus by hooking. Flush
the FSD caches, redirect all disk IRPs to the queue, then wait for all
previously sent disk IRPs to complete, then do the hooking to detach PCIHDD,
the execute the queue of IRPs and stop redirection.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Thanks for answers guys,
>
> Tim Roberts wrote:
> > There is no solution to this. Whatever you do, they can undo, and in
> > the process of implementing it, you will unintentionally break some
> > useful scenario used by a legitimate driver.
>
> Yes this is also my point of concern , possibility of breaking legimate
driver. We have I would 20mil installation around the world and I have no idea
what other third-party software might be used on all the systems.
>
> MM wrote:
>
> >Re: How to not allow attach to lower device
> >Also, isn’t PCIHDD.sys part of the virus? If so, why are you even
> >bothering with this? Once the system is compromised, it all becomes a
> >waste of time until the system is clean.
>
> pcihdd.sys indeed a part of the virus.
> Our product is restart-and-restore product (Deep Freeze) and if after restart
that crap is still there , it means we have failed, and I have to find a
workaround anyhow.
>
Maxim , we are not an antivirus product. However, one of the selling points is :
“Regardless of the changes made to a workstation, simply restart to reset the computer to its original state. The result is a protected, parallel network, free of viruses and unwanted programs”.
And because deepfreeze is way low in the stack the above statement was true for the last 6-7 years.
The are similiar products as DF, but they are FS-filters, and they are not so robust, quick and the most important popular.
What do you mean by hooking ? SSDT hook ?
So, you’re a blockwise volatile boot product like our
ShadowUser/Server/Surfer 
OK, then the PCIHDD virus is cheating you and attaches itself below you
on a booted machine without a reboot.
Hooking as described by me in the previous message seems to be the best way
to hit PCIHDD virus.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Maxim , we are not an antivirus product. However, one of the selling points
is :
> “Regardless of the changes made to a workstation, simply restart to reset the
computer to its original state. The result is a protected, parallel network,
free of viruses and unwanted programs”.
>
> And because deepfreeze is way low in the stack the above statement was true
for the last 6-7 years.
> The are similiar products as DF, but they are FS-filters, and they are not so
robust, quick and the most important popular.
>
> What do you mean by hooking ? SSDT hook ?
>
>
Yes, Maxim , pretty much as Shadow* products 
I thought it was clear from my first post that pcihdd attaches below us, I guess I could make it more clear.
I am not really clear about your solution.
How would I determine that pcihdd has attached to diskdrive device ?
> then wait for all previously sent disk IRPs to complete
How?
The rest is pretty much clear (and no, it’s not about
SSDT hooking, my guess is that Maxim talks about hooking
handlers in the lowest-possible driver dispatch table directly),
but for this flush-and-wait part I don’t see any other solution
except to wait for, say, 1 second (and pray a lot).
Is there a rational way?
To wait for 2 secs and pray less does not count…
-------------- Original message --------------
From: “Maxim S. Shatskih”
> Are you an antivirus product?
>
> For all products except antivirus, it is a good idea to just fail any
> guarantees on a virus-infected machine.
>
> Also: if PCIHDD virus was caught during your “volatile” session, then
> wouldn’t your rollback on reboot destroy this virus?
>
> Prohibiting all disk filters is a bad idea. All companies whose products
> require the disk filter would post the notice on their websites about “do not
> use DeepFreeze - it violates the Microsoft-imposed rules and thus causing
> interops with our product” or such.
>
> So, the worst case for you is to cut away PCIHDD virus by hooking. Flush
> the FSD caches, redirect all disk IRPs to the queue, then wait for all
> previously sent disk IRPs to complete, then do the hooking to detach PCIHDD,
> the execute the queue of IRPs and stop redirection.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> wrote in message news:xxxxx@ntdev…
> > Thanks for answers guys,
> >
> > Tim Roberts wrote:
> > > There is no solution to this. Whatever you do, they can undo, and in
> > > the process of implementing it, you will unintentionally break some
> > > useful scenario used by a legitimate driver.
> >
> > Yes this is also my point of concern , possibility of breaking legimate
> driver. We have I would 20mil installation around the world and I have no idea
> what other third-party software might be used on all the systems.
> >
> > MM wrote:
> >
> > >Re: How to not allow attach to lower device
> > >Also, isn’t PCIHDD.sys part of the virus? If so, why are you even
> > >bothering with this? Once the system is compromised, it all becomes a
> > >waste of time until the system is clean.
> >
> > pcihdd.sys indeed a part of the virus.
> > Our product is restart-and-restore product (Deep Freeze) and if after restart
> that crap is still there , it means we have failed, and I have to find a
> workaround anyhow.
> >
>
>
> —
> 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
> I am not really clear about your solution.
How would I determine that pcihdd has attached to diskdrive device ?
Scan the attachment chain below you by traversing the ->NextDevice list, query
the driver object name for each device.
It is safe to do while your DO is alive.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> The rest is pretty much clear (and no, it’s not about
SSDT hooking, my guess is that Maxim talks about hooking
handlers in the lowest-possible driver dispatch table directly),
Or hooking the attachment chain.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
No, it is not safe to do since you cannot acquire the lock which controls this list. Prefast for drivers will mark this as a warning btw.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, November 26, 2007 2:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to not allow attach to lower device
I am not really clear about your solution.
How would I determine that pcihdd has attached to diskdrive device ?
Scan the attachment chain below you by traversing the ->NextDevice list, query
the driver object name for each device.
It is safe to do while your DO is alive.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
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
Maxim, I think traversing attachment chain might not work in this case , because pcihdd getting PDO of lower device and using it to write. So pcihdd should not be in the device stack.
What you you think about this method which is combination of yours and Alexs idea.
- Hook IRP_MJ_WRITE in the dispatch table of diskdrive driver
- every write traverse list up to see if my driver is in the stack , if not then complete with status_success
Thanks,
Igor.
Why is this not safe in a PnP stack if you’re synchronizing with
MN_REMOVE_DEVICE?
Detaching virii on-the-fly means - violating lots of rules, I understand
this very well.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Doron Holan” wrote in message news:xxxxx@ntdev…
No, it is not safe to do since you cannot acquire the lock which controls this
list. Prefast for drivers will mark this as a warning btw.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, November 26, 2007 2:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to not allow attach to lower device
> I am not really clear about your solution.
> How would I determine that pcihdd has attached to diskdrive device ?
Scan the attachment chain below you by traversing the ->NextDevice list, query
the driver object name for each device.
It is safe to do while your DO is alive.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
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
Are you sure the IRQL in write path is OK for getting driver object names?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Maxim, I think traversing attachment chain might not work in this case ,
because pcihdd getting PDO of lower device and using it to write. So pcihdd
should not be in the device stack.
>
> What you you think about this method which is combination of yours and Alexs
idea.
> 1. Hook IRP_MJ_WRITE in the dispatch table of diskdrive driver
> 2. every write traverse list up to see if my driver is in the stack , if not
then complete with status_success
>
>
> Thanks,
> Igor.
>
Igor Zagoruchenko wrote:
Maxim, I think traversing attachment chain might not work in this
case , because pcihdd getting PDO of lower device and using it
to write. So pcihdd should not be in the device stack.
I thought you could only talk directly to the PDO if you were in the device stack itself. Otherwise you only could attach to the top of another stack.
The list is only meant to be traversed in very certain scenarios. On the fly traversal when the driver is running is not one of them. If it were, there would be an API for you to use to traverse the list safely
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, November 26, 2007 3:02 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:How to not allow attach to lower device
Why is this not safe in a PnP stack if you’re synchronizing with
MN_REMOVE_DEVICE?
Detaching virii on-the-fly means - violating lots of rules, I understand
this very well.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Doron Holan” wrote in message news:xxxxx@ntdev…
No, it is not safe to do since you cannot acquire the lock which controls this
list. Prefast for drivers will mark this as a warning btw.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, November 26, 2007 2:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to not allow attach to lower device
> I am not really clear about your solution.
> How would I determine that pcihdd has attached to diskdrive device ?
Scan the attachment chain below you by traversing the ->NextDevice list, query
the driver object name for each device.
It is safe to do while your DO is alive.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
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
—
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