Doron,
what would you suggest ?
The reason I’ve asked here is because I know there is no “proper” way of blocking that psihdd driver.
We cannot tell our customers to run only as non-administrator. So I have to fix this thing assuming that that can install and start their driver.
Thanks,
Igor.
Igor,
Even if you could walk the chain you won’t see the instance of psihdd
since they are patching the dispatch table thus they are not in the call
chain.
I did figure out a way of determining this in general but since I have a
competing product …
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
xxxxx@shaw.ca wrote:
Doron,
what would you suggest ?
The reason I’ve asked here is because I know there is no “proper” way of blocking that psihdd driver.
We cannot tell our customers to run only as non-administrator. So I have to fix this thing assuming that that can install and start their driver.Thanks,
Igor.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Well, since I don’t have a competing product here is how I would do it ;). You have the PDO which means you can get the PDRIVER_OBJECT from it. DriverStart gives you the base address (which you can also get by calling AuxKlibQueryModuleInformation which is more documented) and DriverSize. You can then inspect each PDRIVER_DISPATCH function in the MajorFunction array and see if the pointer value falls into the driver’s image range (DriverStart >= addr && add <= DriverStart+DriverSize) or equal to the default ntoskrnl Io routine (can’t remember the name offhand, but it is the default value in your PDRIVER_OBJECT’s MajorFunction routine so you can just capture that value on start). If it fails both checks, it is probably hooked. You could go even farther and check the function pointer value to see if it is in the range of any loaded driver (again you can get the list of loaded drivers with their ImageBase values via AuxKlibQueryModuleInformation)
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Monday, November 26, 2007 5:37 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to not allow attach to lower device
Igor,
Even if you could walk the chain you won’t see the instance of psihdd
since they are patching the dispatch table thus they are not in the call
chain.
I did figure out a way of determining this in general but since I have a
competing product …
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
xxxxx@shaw.ca wrote:
Doron,
what would you suggest ?
The reason I’ve asked here is because I know there is no “proper” way of blocking that psihdd driver.
We cannot tell our customers to run only as non-administrator. So I have to fix this thing assuming that that can install and start their driver.Thanks,
Igor.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo 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
What I suggest is that you don’t bother. If another driver is loaded, your hosed. Whatever you do to check for the bad driver, they can undo it or patch your code or do any number of other things that will circumvent your check.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shaw.ca
Sent: Monday, November 26, 2007 4:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to not allow attach to lower device
Doron,
what would you suggest ?
The reason I’ve asked here is because I know there is no “proper” way of blocking that psihdd driver.
We cannot tell our customers to run only as non-administrator. So I have to fix this thing assuming that that can install and start their driver.
Thanks,
Igor.
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
Doron, thanks.
In general, I’d say this is true, but for something that’s similar to an
anti-viral product, it’s always going to be a constant battle of stroke
and counterstroke no matter what anyone does. Perhaps it’s a hopeless
struggle, but lots of people seem interested in fighting it anyway.
It doesn’t really matter if an existing virus “could” do something if it
doesn’t, and there’s still value (albeit limited) in combating that
problem today and responding to new threats as they emerge.
Doron Holan wrote:
What I suggest is that you don’t bother. If another driver is loaded, your hosed. Whatever you do to check for the bad driver, they can undo it or patch your code or do any number of other things that will circumvent your check.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shaw.ca
Sent: Monday, November 26, 2007 4:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to not allow attach to lower deviceDoron,
what would you suggest ?
The reason I’ve asked here is because I know there is no “proper” way of blocking that psihdd driver.
We cannot tell our customers to run only as non-administrator. So I have to fix this thing assuming that that can install and start their driver.Thanks,
Igor.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)
Mark,
These “crappy” products work nearly always. And “properly written software”
does not work quite often. Or
better say “works from time to time”. And as the user needs recorded DVD and
not a coaster I’d double think
about what’s crappy and what’s not 
Anton
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 26, 2007 10:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to not allow attach to lower device
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
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
Well as the saying goes “your mileage may vary”. The inability of
various cd/dvd related burning products to work and play well with other
software in the system is legend. Each, on its own, might indeed be
quite capable of burning the right bits. The problem is that they rarely
end up on users systems running that way.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anton A.
Kolomyeytsev
Sent: Wednesday, November 28, 2007 4:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to not allow attach to lower device
Mark,
These “crappy” products work nearly always. And “properly written
software”
does not work quite often. Or
better say “works from time to time”. And as the user needs recorded DVD
and
not a coaster I’d double think
about what’s crappy and what’s not
Anton
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 26, 2007 10:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to not allow attach to lower device
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
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
You’ve missed the point… The software you call “crappy” can perfectly
co-exist and work just
fine with ANY other burning app on the same machine. As it will feed it’s
commands directly to the burner.
“Properly written” stuff will fight for stack load order and the one sitting
lower will PROBABLY work better.
I don’t want to start another “holy war” but in a nutshell - going blessed
way in this particular case will bring you
to the middle of the nowhere
Anton
P.S. You can drop me an e-mail and I’ll share some names and numbers with
you. I mean statistics. If you want of course
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Wednesday, November 28, 2007 11:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to not allow attach to lower device
Well as the saying goes “your mileage may vary”. The inability of
various cd/dvd related burning products to work and play well with other
software in the system is legend. Each, on its own, might indeed be
quite capable of burning the right bits. The problem is that they rarely
end up on users systems running that way.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anton A.
Kolomyeytsev
Sent: Wednesday, November 28, 2007 4:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to not allow attach to lower device
Mark,
These “crappy” products work nearly always. And “properly written
software”
does not work quite often. Or
better say “works from time to time”. And as the user needs recorded DVD
and
not a coaster I’d double think
about what’s crappy and what’s not
Anton
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Monday, November 26, 2007 10:29 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to not allow attach to lower device
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
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
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
Anton,
Yes it will work with other burning software but that is the exception
rather than the rule. What this TOTAL GARBAGE (sorry crappy is way too
mild) will not do is allow someone to filter or control things when needed.
I have worked on projects where a storage filter is an absolute must, and
then this stupid shit comes along and bypasses the world. Of course the
platform is blamed not the garbage software.
–
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
“Anton A. Kolomyeytsev” wrote in message
news:xxxxx@ntdev…
> You’ve missed the point… The software you call “crappy” can perfectly
> co-exist and work just
> fine with ANY other burning app on the same machine. As it will feed it’s
> commands directly to the burner.
> “Properly written” stuff will fight for stack load order and the one
> sitting
> lower will PROBABLY work better.
> I don’t want to start another “holy war” but in a nutshell - going blessed
> way in this particular case will bring you
> to the middle of the nowhere
>
> Anton
>
> P.S. You can drop me an e-mail and I’ll share some names and numbers with
> you. I mean statistics. If you want of course
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
> Sent: Wednesday, November 28, 2007 11:47 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] How to not allow attach to lower device
>
> Well as the saying goes “your mileage may vary”. The inability of
> various cd/dvd related burning products to work and play well with other
> software in the system is legend. Each, on its own, might indeed be
> quite capable of burning the right bits. The problem is that they rarely
> end up on users systems running that way.
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Anton A.
> Kolomyeytsev
> Sent: Wednesday, November 28, 2007 4:36 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] How to not allow attach to lower device
>
> Mark,
>
> These “crappy” products work nearly always. And “properly written
> software”
> does not work quite often. Or
> better say “works from time to time”. And as the user needs recorded DVD
> and
> not a coaster I’d double think
> about what’s crappy and what’s not
>
> Anton
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
> Sent: Monday, November 26, 2007 10:29 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] How to not allow attach to lower device
>
> 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
>
> —
> 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
>
> —
> 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
>
>
Don.
Other than youe assertion that the platform is blamed, I agree with you,
and I think that you actually understate the issue, which is very
uncharacteristic. In my mind, what really makes this whole operation
(the original subject, not burning software, about which I know nothing)
problematic is this:
'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.
This product suffers from a flawed design; it just took a while to find
something that exploits it. I’m not doubting their intentions, or that
a lot of people apparently use it quite happily and most of them will
continue to be able to do so without issue, or the dev in any way, no
matter what he chooses, as he has a job to do and bills to pay, but when
you get to this point - a system that is supposedly protected from any
change after one boot is now compromised - there is no responsible
workaround, as you’re in bluescreen territory. It would be like an AV
saying that the know about a virus, can’t remove it, but not to to
worry, you’re all good, because we changed someone else’s software in a
way that will break still someone else’s software, so everything is
cool. The product doesn’t work, and they’ve got acknowledge this and
fix it so that it meets the goals it states that it meets. Even leaving
out that this approach will break break other’s software, messing with
an inbox driver by patching of some sort certainly doesn’t qualify as a
way to implement a rollback by reboot, and it probably crosses the very,
very fine line between security product and malware. I assume that the
user is notified of this problem; if they’re not, then, no matter the
intention, this is just malware.
mm
Don Burn wrote:
Anton,
Yes it will work with other burning software but that is the exception
rather than the rule. What this TOTAL GARBAGE (sorry crappy is way too
mild) will not do is allow someone to filter or control things when needed.
I have worked on projects where a storage filter is an absolute must, and
then this stupid shit comes along and bypasses the world. Of course the
platform is blamed not the garbage software.
Martin O’Brien wrote:
Other than youe assertion that the platform is blamed, I agree with
you, and I think that you actually understate the issue, which is very
uncharacteristic. In my mind, what really makes this whole operation
(the original subject, not burning software, about which I know
nothing) problematic is this:'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.This product suffers from a flawed design; it just took a while to
find something that exploits it. I’m not doubting their intentions,
or that a lot of people apparently use it quite happily and most of
them will continue to be able to do so without issue, or the dev in
any way, no matter what he chooses, as he has a job to do and bills to
pay, but when you get to this point - a system that is supposedly
protected from any change after one boot is now compromised - there
is no responsible workaround, as you’re in bluescreen territory. …
The product doesn’t work, and they’ve got acknowledge this and fix it
so that it meets the goals it states that it meets.
Your position is not reasonable. You are expecting this company to have
pre-anticipated attack vectors that were not even considered remotely
possible at the time the product was written. Indeed, I would assert
that solving the problem as you have stated it is equivalent to solving
the Turing stopping problem.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim:
Perhaps I wasn’t clear, but I wasn’t commenting at all on what this
company did or did not do in the past; I was talking about they are
doing right now, about this particular problem and the implications of
those choices with regards to the very black and white statements that
they make about their product being able to guarantee a perfect rollback
of any and all changes made to a system by just rebooting. The dev is
talking about developing a workaround for after they reboot and know
they’ve failed, which the dev states. By any reasonable definition,
this isn’t a rollback, and when what you can’t rollback is an explicit,
malicious mechanism that provides a mean to write directly to disk,
circumventing the monitoring you use to measure what to rollback, you
are indeed in to Turing territory and no attestation is possible at that
point, and certainly not going forward, no matter what you patch. This
problem, as you, I and most everyone else who commented on it has
stated, is a complete waste of time, except that it’s profitable. What
I am saying is that is if they can’t fix it, which they can’t, and
certainly can not without replacing the disk drivers themselves rather
than providing filters, then they must restate what their product does.
This is what everyone else does, so I don’t see it as unreasonable
that they should have to do it. Unfortunately for them, a rollback is a
very black and white thing, so this puts them in a difficult position of
having to say something along the lines of if your disk drivers or what
not are compromised, then our product can no longer provide rollback
capability. The bottom line in my mind is that if after you rollback
there are still things that shouldn’t be there, then you can’t call it a
rollback anymore. I see don’t see this as unreasonable.
mm
Tim Roberts wrote:
Martin O’Brien wrote:
> Other than youe assertion that the platform is blamed, I agree with
> you, and I think that you actually understate the issue, which is very
> uncharacteristic. In my mind, what really makes this whole operation
> (the original subject, not burning software, about which I know
> nothing) problematic is this:
>
> '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.
>
> This product suffers from a flawed design; it just took a while to
> find something that exploits it. I’m not doubting their intentions,
> or that a lot of people apparently use it quite happily and most of
> them will continue to be able to do so without issue, or the dev in
> any way, no matter what he chooses, as he has a job to do and bills to
> pay, but when you get to this point - a system that is supposedly
> protected from any change after one boot is now compromised - there
> is no responsible workaround, as you’re in bluescreen territory. …
> The product doesn’t work, and they’ve got acknowledge this and fix it
> so that it meets the goals it states that it meets.Your position is not reasonable. You are expecting this company to have
pre-anticipated attack vectors that were not even considered remotely
possible at the time the product was written. Indeed, I would assert
that solving the problem as you have stated it is equivalent to solving
the Turing stopping problem.
Small correction. The part about replacing the disk drivers instead of
using filters, should read using them in addition to, as in addressing
the the whole stack so that they don’t have to break other applications
attaching to it, at least in theory. Still a seriously tall order, that
probably isn’t allowed on some platforms.
mm
Martin O’Brien wrote:
Tim:
Perhaps I wasn’t clear, but I wasn’t commenting at all on what this
company did or did not do in the past; I was talking about they are
doing right now, about this particular problem and the implications of
those choices with regards to the very black and white statements that
they make about their product being able to guarantee a perfect rollback
of any and all changes made to a system by just rebooting. The dev is
talking about developing a workaround for after they reboot and know
they’ve failed, which the dev states. By any reasonable definition,
this isn’t a rollback, and when what you can’t rollback is an explicit,
malicious mechanism that provides a mean to write directly to disk,
circumventing the monitoring you use to measure what to rollback, you
are indeed in to Turing territory and no attestation is possible at that
point, and certainly not going forward, no matter what you patch. This
problem, as you, I and most everyone else who commented on it has
stated, is a complete waste of time, except that it’s profitable. What
I am saying is that is if they can’t fix it, which they can’t, and
certainly can not without replacing the disk drivers themselves rather
than providing filters, then they must restate what their product does.
This is what everyone else does, so I don’t see it as unreasonable that
they should have to do it. Unfortunately for them, a rollback is a very
black and white thing, so this puts them in a difficult position of
having to say something along the lines of if your disk drivers or what
not are compromised, then our product can no longer provide rollback
capability. The bottom line in my mind is that if after you rollback
there are still things that shouldn’t be there, then you can’t call it a
rollback anymore. I see don’t see this as unreasonable.mm
Tim Roberts wrote:
> Martin O’Brien wrote:
>> Other than youe assertion that the platform is blamed, I agree with
>> you, and I think that you actually understate the issue, which is very
>> uncharacteristic. In my mind, what really makes this whole operation
>> (the original subject, not burning software, about which I know
>> nothing) problematic is this:
>>
>> '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.
>>
>> This product suffers from a flawed design; it just took a while to
>> find something that exploits it. I’m not doubting their intentions,
>> or that a lot of people apparently use it quite happily and most of
>> them will continue to be able to do so without issue, or the dev in
>> any way, no matter what he chooses, as he has a job to do and bills to
>> pay, but when you get to this point - a system that is supposedly
>> protected from any change after one boot is now compromised - there
>> is no responsible workaround, as you’re in bluescreen territory. …
>> The product doesn’t work, and they’ve got acknowledge this and fix it
>> so that it meets the goals it states that it meets.
>
> Your position is not reasonable. You are expecting this company to have
> pre-anticipated attack vectors that were not even considered remotely
> possible at the time the product was written. Indeed, I would assert
> that solving the problem as you have stated it is equivalent to solving
> the Turing stopping problem.
>
HI,
Hook can work in this case. Hint: please see function IoCallDriver’s disassembling codes. And you will find that you can write a function similar to IoCallDriver, but your function can jump over some lower drivers and directly reach the driver you want.
Many moons ago, when I was involved in this kind of stuff ( antivirus and
firewall ), I mentioned that it is a Turing problem, and was proved by some
guy I don’t even remeber the name.
Sure it is a wacko idea to solve this way or thatway. Yes kills the very
stability of some platforms. Yes it is ugly as hell. But look the industry
is such a shit sometimes, and the guys in the frontlne has to firefight.
What would you do? Walkout, take all of clothes off, and shut out loud
“Euroka …”
Come on man, this is what that AV business is about - Its your move, okay
now it is my move, now it is yours.
It is bad enough that users would run under admin privilage, but what if
that is the case, and howbest could someone slove it, instead of giving
up… Sure it is not the end of all the attack …
*******Sorry to anyone***** who likes to see things done in order ( works
all the time, and a good citizen to the system ) but what the OP can do (
not perfect ) is -
OP briefly mentioned that it is 20Million (user) at stake. Asking each one
to shutdown the machines, run some admin utility to clean the machines (
basically knocking off the krnl mode component that is acting as virus ) and
restart is bit of headache!. Though, it’s been the way lot of antivious
software worked in the past !!!
If the OP really need to clean such a patch while the system is running (
some of the options are, and all of them are hacks ) -
Once it notice that some of the dispatches of the lower driver (
including its own driver) in the chain are patched, it might have to replace
back ( if it knows the original addresses of those dispatches). How would
someone know its immediate lower driver dispatch addresses??? From the
device object to driver object and then look at the start address of the
driver module and length of the module to findout if any of the current
dispatch routines belong outside the range. If so, then replace with the
original dispatch address.
Another way to know the size is to really load the module of your
attached device, then get the size???
The best case would be to kill the registry entries for the
virus-kmodecomponent ( but it could be an on the fly installed type ).
-pro
----- Original Message -----
From: “Martin O’Brien”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, November 28, 2007 5:35 PM
Subject: Re:[ntdev] How to not allow attach to lower device
> Small correction. The part about replacing the disk drivers instead of
> using filters, should read using them in addition to, as in addressing the
> the whole stack so that they don’t have to break other applications
> attaching to it, at least in theory. Still a seriously tall order, that
> probably isn’t allowed on some platforms.
>
> mm
>
> Martin O’Brien wrote:
>> Tim:
>>
>> Perhaps I wasn’t clear, but I wasn’t commenting at all on what this
>> company did or did not do in the past; I was talking about they are doing
>> right now, about this particular problem and the implications of those
>> choices with regards to the very black and white statements that they
>> make about their product being able to guarantee a perfect rollback of
>> any and all changes made to a system by just rebooting. The dev is
>> talking about developing a workaround for after they reboot and know
>> they’ve failed, which the dev states. By any reasonable definition, this
>> isn’t a rollback, and when what you can’t rollback is an explicit,
>> malicious mechanism that provides a mean to write directly to disk,
>> circumventing the monitoring you use to measure what to rollback, you are
>> indeed in to Turing territory and no attestation is possible at that
>> point, and certainly not going forward, no matter what you patch. This
>> problem, as you, I and most everyone else who commented on it has stated,
>> is a complete waste of time, except that it’s profitable. What I am
>> saying is that is if they can’t fix it, which they can’t, and certainly
>> can not without replacing the disk drivers themselves rather than
>> providing filters, then they must restate what their product does. This
>> is what everyone else does, so I don’t see it as unreasonable that they
>> should have to do it. Unfortunately for them, a rollback is a very black
>> and white thing, so this puts them in a difficult position of having to
>> say something along the lines of if your disk drivers or what not are
>> compromised, then our product can no longer provide rollback capability.
>> The bottom line in my mind is that if after you rollback there are still
>> things that shouldn’t be there, then you can’t call it a rollback
>> anymore. I see don’t see this as unreasonable.
>>
>> mm
>>
>>
>>
>> Tim Roberts wrote:
>>> Martin O’Brien wrote:
>>>> Other than youe assertion that the platform is blamed, I agree with
>>>> you, and I think that you actually understate the issue, which is very
>>>> uncharacteristic. In my mind, what really makes this whole operation
>>>> (the original subject, not burning software, about which I know
>>>> nothing) problematic is this:
>>>>
>>>> '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.
>>>>
>>>> This product suffers from a flawed design; it just took a while to
>>>> find something that exploits it. I’m not doubting their intentions,
>>>> or that a lot of people apparently use it quite happily and most of
>>>> them will continue to be able to do so without issue, or the dev in
>>>> any way, no matter what he chooses, as he has a job to do and bills to
>>>> pay, but when you get to this point - a system that is supposedly
>>>> protected from any change after one boot is now compromised - there
>>>> is no responsible workaround, as you’re in bluescreen territory. …
>>>> The product doesn’t work, and they’ve got acknowledge this and fix it
>>>> so that it meets the goals it states that it meets.
>>>
>>> Your position is not reasonable. You are expecting this company to have
>>> pre-anticipated attack vectors that were not even considered remotely
>>> possible at the time the product was written. Indeed, I would assert
>>> that solving the problem as you have stated it is equivalent to solving
>>> the Turing stopping problem.
>>>
>>
>
> —
> 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
Nero works from time to time? news for me.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Anton A. Kolomyeytsev” wrote in message
news:xxxxx@ntdev…
> Mark,
>
> These “crappy” products work nearly always. And “properly written software”
> does not work quite often. Or
> better say “works from time to time”. And as the user needs recorded DVD and
> not a coaster I’d double think
> about what’s crappy and what’s not
>
> Anton
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
> Sent: Monday, November 26, 2007 10:29 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] How to not allow attach to lower device
>
> 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
>
> —
> 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
>
>
Just to further muddy the waters, I was not obliquely referring to nero.
That anyone thought I was is their imagination and not my intention. And my
only point was that products, even if they work perfectly by themselves,
that bypass the established mechanisms for filtering, break other products
that legitimately need to filter that stack and are not breaking the rules.
That said, I long ago got rid of all dvd/cd burning products from the
systems I need to use to burn dvds. Instead I rely on the more mundane
dvdburn tool from the resource kit, as it works for what I need it to do and
it does not alter my system in unexpected ways.
On Nov 28, 2007 11:38 PM, Maxim S. Shatskih wrote:
> Nero works from time to time? news for me.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Anton A. Kolomyeytsev” wrote in message
> news:xxxxx@ntdev…
> > Mark,
> >
> > These “crappy” products work nearly always. And “properly written
> software”
> > does not work quite often. Or
> > better say “works from time to time”. And as the user needs recorded DVD
> and
> > not a coaster I’d double think
> > about what’s crappy and what’s not
> >
> > Anton
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
> > Sent: Monday, November 26, 2007 10:29 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] How to not allow attach to lower device
> >
> > 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
> >
> > —
> > 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
>
–
Mark Roddy
> Once the system is compromised, it all becomes a waste of time until the system is clean.
I just love this approach - if everyone believes that making compromised system verify its own integrity is pointless exercise in itself, how on Earth the machine may possible become clean then???
Sorry, but this is what detection and cleaning are all about - you have to set up some trap into
which a piece of malware is just bound to fall, and, hence, reveal its presence. This part is relatively easy. When it comes to identification (i.e. what registry entries have to be removed in order to make sure that malicious binary in question lays passively on the disk upon the next boot so that it can get deleted), things become much more complicated - some rootkits tend to cling to life strenuously, and, indeed, easily defeat all “conventional” attempts to neutralize them. However, it does not mean that cleaning them up is a kind of thing that is not worth even trying…
Anton Bassov
anton bassov wrote:
I just love this approach - if everyone believes that making compromised
system verify its own integrity is pointless exercise in itself, how on Earth
the machine may possible become clean then???
format C: /u /q /s