> The problem is do it in 2500 computers
Booting each machine off proper CD is the simplest possible thing.
Preparing a proper WinPE CD with a proper script is 10-20 times easier then develop the filter driver, test it and deploy on 2500 machines.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Well good luck with that effort. Your best bet is to remove the root kit
while booted from an alternate os image.
Mark Roddy
On Sun, Jan 18, 2009 at 1:55 PM, Samir Sousa wrote:
> Well, We are trying to build an application using NT Native Api.
> This application is for to delete some files used by a trojan, with most
> popular AV don?t detect here and also don?t delete the main files.
> The problem is:
> This trojan install a .sys(Image sys Driver) with protects, all files used
> by trojan to be deleted in boot process.
> In other way, we cannot change any information from the registry, about
> this trojan, because in Windows Environment, this trojan have a dll hooking
> any change into their registry values, blocking the changes and in some
> cases, rolling back any changes, we try to do, and of course, we cannot
> delete those files, because, this dll, protect?s all yours owns files,
> including the .sys file.
> We try to insert a function native from NT, such as NTUnload, but don?t
> work, I think because the driver don?t have a section with instructions to
> unload the driver.
> We can delete this files using NTDeleteFIle from NT Native Api, in our
> executable, because the driver from trojan load before US, blocking the
> function and we see a message(STATUS_SHARING_VIOLATION). So, we don?t have
> any ideas to delete this files, they don?t infect any other?s files, they
> only intall Yours own files to monitoring PC activity and to try get Bank
> Information.
> So we don?t have more any ideas how we can delete the files.
>
> Can someone help us?
>
> By the way, if is needed, we can send here, or in private e-mail our source
> code, witch we try to delete this files, who we build a smaller application
> in NT Native Api.
>
> Thanks for Your help.
>
> --------------------------------------------------
> From: “Doron Holan”
> Sent: Sunday, January 18, 2009 2:19 PM
> To: “Windows System Software Devs Interest List”
> Subject: RE: [ntdev] Change boot driver process.
>
>
> What are you trying to do by changing the boot order? There might be an
>> easier way to do what you want without touching the boot order
>>
>> d
>>
>> Sent from my phone with no t9, all spilling mistakes are not intentional.
>>
>> -----Original Message-----
>> From: xxxxx@hotmail.com
>> Sent: Sunday, January 18, 2009 2:41 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Change boot driver process.
>>
>>
>> Have a way to change the driver boot process or put my driver before
>> others load in Windows?
>>
>>
>> —
>> 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
>
Maxim S. Shatskih wrote:
> The problem is do it in 2500 computers
Booting each machine off proper CD is the simplest possible thing.
Preparing a proper WinPE CD with a proper script is 10-20 times easier then develop the filter driver, test it and deploy on 2500 machines.
Can it be done this way:
the native executable or driver reboots from the WinPE/BartPE/Linux CD
(after checking that it is the correct CD)
then the cleanup app that runs from the CD will remove the former, so
the next boot from the hard disk will go as usual.
The procedure will be as easy for the users as possible:
1. Deliver the CD to users, or instruct them to burn the CD.
2. Instruct the user to install something from that CD
( this will cause reboot from the cd on the next boot)
3. Reboot with the CD inserted
This will spare them from discovering in the BIOS how to boot from CD,
and then change it back (it’s a mentality issue… can’t be helped)
Regards,
–PA
I don’t know whether this malware is sitting into your File System stack or
storage stack or not.
But one solution is not delete the file. Just try to corrupt it by
obfuscating it’s PE header.
To do this, try doing a raw disk read/write (again it has been discussed
many times on the list as a dangerous practice)
Obviously it will be a riskier job to do on end user’s machine (So before
corrupting it, take a back up of it at your quarantine location)
After you have corrupted it, Windows will not load it and on next boot you
can delete it.
Regards
Deepak
On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. wrote:
> Maxim S. Shatskih wrote:
>
>> The problem is do it in 2500 computers
>>>
>>
>> Booting each machine off proper CD is the simplest possible thing.
>>
>> Preparing a proper WinPE CD with a proper script is 10-20 times easier
>> then develop the filter driver, test it and deploy on 2500 machines.
>>
>
> Can it be done this way:
> the native executable or driver reboots from the WinPE/BartPE/Linux CD
> (after checking that it is the correct CD)
> then the cleanup app that runs from the CD will remove the former, so the
> next boot from the hard disk will go as usual.
>
> The procedure will be as easy for the users as possible:
>
> 1. Deliver the CD to users, or instruct them to burn the CD.
> 2. Instruct the user to install something from that CD
> ( this will cause reboot from the cd on the next boot)
> 3. Reboot with the CD inserted
>
> This will spare them from discovering in the BIOS how to boot from CD, and
> then change it back (it’s a mentality issue… can’t be helped)
>
> Regards,
> --PA
>
>
> —
> 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
>
How can I do this?
Regards.
From: Deepak Gupta
Sent: Monday, January 19, 2009 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Change boot driver process.
I don’t know whether this malware is sitting into your File System stack or storage stack or not.
But one solution is not delete the file. Just try to corrupt it by obfuscating it’s PE header.
To do this, try doing a raw disk read/write (again it has been discussed many times on the list as a dangerous practice)
Obviously it will be a riskier job to do on end user’s machine (So before corrupting it, take a back up of it at your quarantine location)
After you have corrupted it, Windows will not load it and on next boot you can delete it.
Regards
Deepak
On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. wrote:
Maxim S. Shatskih wrote:
The problem is do it in 2500 computers
Booting each machine off proper CD is the simplest possible thing.
Preparing a proper WinPE CD with a proper script is 10-20 times easier then develop the filter driver, test it and deploy on 2500 machines.
Can it be done this way:
the native executable or driver reboots from the WinPE/BartPE/Linux CD
(after checking that it is the correct CD)
then the cleanup app that runs from the CD will remove the former, so the next boot from the hard disk will go as usual.
The procedure will be as easy for the users as possible:
1. Deliver the CD to users, or instruct them to burn the CD.
2. Instruct the user to install something from that CD
( this will cause reboot from the cd on the next boot)
3. Reboot with the CD inserted
This will spare them from discovering in the BIOS how to boot from CD, and then change it back (it’s a mentality issue… can’t be helped)
Regards,
--PA
—
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
Have any way to do this in NT Native Api?
Regards.
From: Deepak Gupta
Sent: Monday, January 19, 2009 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Change boot driver process.
I don’t know whether this malware is sitting into your File System stack or storage stack or not.
But one solution is not delete the file. Just try to corrupt it by obfuscating it’s PE header.
To do this, try doing a raw disk read/write (again it has been discussed many times on the list as a dangerous practice)
Obviously it will be a riskier job to do on end user’s machine (So before corrupting it, take a back up of it at your quarantine location)
After you have corrupted it, Windows will not load it and on next boot you can delete it.
Regards
Deepak
On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. wrote:
Maxim S. Shatskih wrote:
The problem is do it in 2500 computers
Booting each machine off proper CD is the simplest possible thing.
Preparing a proper WinPE CD with a proper script is 10-20 times easier then develop the filter driver, test it and deploy on 2500 machines.
Can it be done this way:
the native executable or driver reboots from the WinPE/BartPE/Linux CD
(after checking that it is the correct CD)
then the cleanup app that runs from the CD will remove the former, so the next boot from the hard disk will go as usual.
The procedure will be as easy for the users as possible:
1. Deliver the CD to users, or instruct them to burn the CD.
2. Instruct the user to install something from that CD
( this will cause reboot from the cd on the next boot)
3. Reboot with the CD inserted
This will spare them from discovering in the BIOS how to boot from CD, and then change it back (it’s a mentality issue… can’t be helped)
Regards,
--PA
—
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
If you corrupt the header, you must realize that it is likely that the
MALWARE driver has marked itself as needed to boot, so basically you have
made the system unusable. I suspect the reason you cannot delete the file
is that the first thing MALWARE does is put up defenses to protect itself,
stopping delete of a file is pretty trivial. If it is a driver, then they
have likely hooked the registry so you cannot remove the entry for the
driver or even make it optional.
Your project is in serious trouble, the questions you are asking are for the
simple cases, most anti-MALWARE have countermeasures, the real problems are
far beyond this, and you don’t understand the simple stuff.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Samir Sousa” wrote in message news:xxxxx@ntdev…
How can I do this?
Regards.
From: Deepak Gupta
Sent: Monday, January 19, 2009 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Change boot driver process.
I don’t know whether this malware is sitting into your File System stack or
storage stack or not.
But one solution is not delete the file. Just try to corrupt it by
obfuscating it’s PE header.
To do this, try doing a raw disk read/write (again it has been discussed
many times on the list as a dangerous practice)
Obviously it will be a riskier job to do on end user’s machine (So before
corrupting it, take a back up of it at your quarantine location)
After you have corrupted it, Windows will not load it and on next boot you
can delete it.
Regards
Deepak
On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. wrote:
Maxim S. Shatskih wrote:
The problem is do it in 2500 computers
Booting each machine off proper CD is the simplest possible thing.
Preparing a proper WinPE CD with a proper script is 10-20 times easier
then develop the filter driver, test it and deploy on 2500 machines.
Can it be done this way:
the native executable or driver reboots from the WinPE/BartPE/Linux CD
(after checking that it is the correct CD)
then the cleanup app that runs from the CD will remove the former, so the
next boot from the hard disk will go as usual.
The procedure will be as easy for the users as possible:
1. Deliver the CD to users, or instruct them to burn the CD.
2. Instruct the user to install something from that CD
( this will cause reboot from the cd on the next boot)
3. Reboot with the CD inserted
This will spare them from discovering in the BIOS how to boot from CD, and
then change it back (it’s a mentality issue… can’t be helped)
Regards,
--PA
—
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
This is some of the worst advice I’ve ever seen posted here. As Don
already mentioned, if the system is configured to ‘require’ the file,
you’re not going to be able to boot.
I’ll give it one last try - the only thing that you, I or anyone else
can safely do in a situation like this is reinstall Windows. Even if
you wrote something that removed the particular file safely, once a
system has been compromised, there really is no reasonable way (if at
all, depending on how you analyze it) to determine the extent to which
it has been compromised, and if you include data in this evaluation,
there’s no way. In addition, I don’t mean this critically, but you
clearly are new to all of this, and as with everyone who’s new, you
don’t know what you’re doing, so you really and truly have absolutely no
chance of getting this to work in a profitable time frame. Whatever
time you envision saving with this method v. reinstalling the 2500
machines will not materialize, and what you will end up with is 2500
machines that you have to debug remotely, and I’m guessing you don’t
know how to use windbg, which in and of itself, is a total deal breaker,
and would keep you busy for at least the next three months, and in the
end, you’re still going to have to reinstall windows everywhere.
mm
Deepak Gupta wrote:
I don’t know whether this malware is sitting into your File System stack
or storage stack or not.But one solution is not delete the file. Just try to corrupt it by
obfuscating it’s PE header.
To do this, try doing a raw disk read/write (again it has been discussed
many times on the list as a dangerous practice)
Obviously it will be a riskier job to do on end user’s machine (So
before corrupting it, take a back up of it at your quarantine location)After you have corrupted it, Windows will not load it and on next boot
you can delete it.Regards
DeepakOn Mon, Jan 19, 2009 at 3:31 PM, Pavel A. > mailto:xxxxx> wrote:
>
> Maxim S. Shatskih wrote:
>
> The problem is do it in 2500 computers
>
>
> Booting each machine off proper CD is the simplest possible thing.
>
> Preparing a proper WinPE CD with a proper script is 10-20 times
> easier then develop the filter driver, test it and deploy on
> 2500 machines.
>
>
> Can it be done this way:
> the native executable or driver reboots from the WinPE/BartPE/Linux CD
> (after checking that it is the correct CD)
> then the cleanup app that runs from the CD will remove the former,
> so the next boot from the hard disk will go as usual.
>
> The procedure will be as easy for the users as possible:
>
> 1. Deliver the CD to users, or instruct them to burn the CD.
> 2. Instruct the user to install something from that CD
> ( this will cause reboot from the cd on the next boot)
> 3. Reboot with the CD inserted
>
> This will spare them from discovering in the BIOS how to boot from
> CD, and then change it back (it’s a mentality issue… can’t be helped)
>
> Regards,
> --PA
>
>
> —
> 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
>
></mailto:xxxxx>
I forgot something. If you’re unwilling to go the reinstall route, at
least consider seeing what can be accomplished via booting to an
alternate image as Mark already suggested, and also give Safe Mode a try.
mm
Martin O’Brien wrote:
This is some of the worst advice I’ve ever seen posted here. As Don
already mentioned, if the system is configured to ‘require’ the file,
you’re not going to be able to boot.I’ll give it one last try - the only thing that you, I or anyone else
can safely do in a situation like this is reinstall Windows. Even if
you wrote something that removed the particular file safely, once a
system has been compromised, there really is no reasonable way (if at
all, depending on how you analyze it) to determine the extent to which
it has been compromised, and if you include data in this evaluation,
there’s no way. In addition, I don’t mean this critically, but you
clearly are new to all of this, and as with everyone who’s new, you
don’t know what you’re doing, so you really and truly have absolutely no
chance of getting this to work in a profitable time frame. Whatever
time you envision saving with this method v. reinstalling the 2500
machines will not materialize, and what you will end up with is 2500
machines that you have to debug remotely, and I’m guessing you don’t
know how to use windbg, which in and of itself, is a total deal breaker,
and would keep you busy for at least the next three months, and in the
end, you’re still going to have to reinstall windows everywhere.mm
Deepak Gupta wrote:
> I don’t know whether this malware is sitting into your File System
> stack or storage stack or not.
>
> But one solution is not delete the file. Just try to corrupt it by
> obfuscating it’s PE header.
> To do this, try doing a raw disk read/write (again it has been
> discussed many times on the list as a dangerous practice)
> Obviously it will be a riskier job to do on end user’s machine (So
> before corrupting it, take a back up of it at your quarantine location)
>
> After you have corrupted it, Windows will not load it and on next boot
> you can delete it.
>
> Regards
> Deepak
>
> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. >> mailto:xxxxx> wrote:
>>
>> Maxim S. Shatskih wrote:
>>
>> The problem is do it in 2500 computers
>>
>>
>> Booting each machine off proper CD is the simplest possible
>> thing.
>>
>> Preparing a proper WinPE CD with a proper script is 10-20 times
>> easier then develop the filter driver, test it and deploy on
>> 2500 machines.
>>
>>
>> Can it be done this way:
>> the native executable or driver reboots from the
>> WinPE/BartPE/Linux CD
>> (after checking that it is the correct CD)
>> then the cleanup app that runs from the CD will remove the former,
>> so the next boot from the hard disk will go as usual.
>>
>> The procedure will be as easy for the users as possible:
>>
>> 1. Deliver the CD to users, or instruct them to burn the CD.
>> 2. Instruct the user to install something from that CD
>> ( this will cause reboot from the cd on the next boot)
>> 3. Reboot with the CD inserted
>>
>> This will spare them from discovering in the BIOS how to boot from
>> CD, and then change it back (it’s a mentality issue… can’t be
>> helped)
>>
>> Regards,
>> --PA
>>
>>
>> —
>> 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
>>
>>
></mailto:xxxxx>
Samir Sousa wrote:
I appreciate your response, and we like to develop the application to
do is, I don´t beliave is impossible, because if they can do, why we
can´t do more better?
Because the slimy, feces-eating virus writers are, collectively, smarter
than you and I. Sorry, but it’s true. Whatever you can do, they can
undo. It’s just a fact. You can’t solve this in an automated way.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Mon, Jan 19, 2009 at 6:50 PM, Samir Sousa wrote:
> Have any way to do this in NT Native Api?
>
Native Applications come very late in system initialization order.
So if a driver component is there which is loading early in boot order, then
there is no use of
having a native application deleting those files.
Cheers
Deepak
>
> Regards.
>
> From: Deepak Gupta
> Sent: Monday, January 19, 2009 9:52 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Change boot driver process.
>
> I don’t know whether this malware is sitting into your File System stack or
> storage stack or not.
>
> But one solution is not delete the file. Just try to corrupt it by
> obfuscating it’s PE header.
> To do this, try doing a raw disk read/write (again it has been discussed
> many times on the list as a dangerous practice)
> Obviously it will be a riskier job to do on end user’s machine (So before
> corrupting it, take a back up of it at your quarantine location)
>
> After you have corrupted it, Windows will not load it and on next boot you
> can delete it.
>
> Regards
> Deepak
>
> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. wrote:
>
>> Maxim S. Shatskih wrote:
>>
>>> The problem is do it in 2500 computers
>>>>
>>>
>>> Booting each machine off proper CD is the simplest possible thing.
>>>
>>> Preparing a proper WinPE CD with a proper script is 10-20 times easier
>>> then develop the filter driver, test it and deploy on 2500 machines.
>>>
>>
>> Can it be done this way:
>> the native executable or driver reboots from the WinPE/BartPE/Linux CD
>> (after checking that it is the correct CD)
>> then the cleanup app that runs from the CD will remove the former, so the
>> next boot from the hard disk will go as usual.
>>
>> The procedure will be as easy for the users as possible:
>>
>> 1. Deliver the CD to users, or instruct them to burn the CD.
>> 2. Instruct the user to install something from that CD
>> ( this will cause reboot from the cd on the next boot)
>> 3. Reboot with the CD inserted
>>
>> This will spare them from discovering in the BIOS how to boot from CD, and
>> then change it back (it’s a mentality issue… can’t be helped)
>>
>> Regards,
>> --PA
>>
>>
>> —
>> 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
>
And you wouldn’t even need to write a native application to do this -
just add an entry to
HKEY_LOCAL_MACHINE\System\Control\CurrentControlSet\Session
Manager\FileRenameOperations
It won’t work, but if he wants to go this route, he could at least just
do this and see that it doesn’t work.
mm
Deepak Gupta wrote:
On Mon, Jan 19, 2009 at 6:50 PM, Samir Sousa > mailto:xxxxx> wrote:
>
> Have any way to do this in NT Native Api?
>
>
> Native Applications come very late in system initialization order.
> So if a driver component is there which is loading early in boot order,
> then there is no use of
> having a native application deleting those files.
>
> Cheers
> Deepak
>
>
> Regards.
>
> From: Deepak Gupta mailto:xxxxx
> Sent: Monday, January 19, 2009 9:52 AM
> To: Windows System Software Devs Interest List
> mailto:xxxxx
> Subject: Re: [ntdev] Change boot driver process.
>
> I don’t know whether this malware is sitting into your File System
> stack or storage stack or not.
>
> But one solution is not delete the file. Just try to corrupt it by
> obfuscating it’s PE header.
> To do this, try doing a raw disk read/write (again it has been
> discussed many times on the list as a dangerous practice)
> Obviously it will be a riskier job to do on end user’s machine (So
> before corrupting it, take a back up of it at your quarantine location)
>
> After you have corrupted it, Windows will not load it and on next
> boot you can delete it.
>
> Regards
> Deepak
>
> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. > mailto:xxxxx> wrote:
>
> Maxim S. Shatskih wrote:
>
> The problem is do it in 2500 computers
>
>
> Booting each machine off proper CD is the simplest possible
> thing.
>
> Preparing a proper WinPE CD with a proper script is 10-20
> times easier then develop the filter driver, test it and
> deploy on 2500 machines.
>
>
> Can it be done this way:
> the native executable or driver reboots from the
> WinPE/BartPE/Linux CD
> (after checking that it is the correct CD)
> then the cleanup app that runs from the CD will remove the
> former, so the next boot from the hard disk will go as usual.
>
> The procedure will be as easy for the users as possible:
>
> 1. Deliver the CD to users, or instruct them to burn the CD.
> 2. Instruct the user to install something from that CD
> ( this will cause reboot from the cd on the next boot)
> 3. Reboot with the CD inserted
>
> This will spare them from discovering in the BIOS how to boot
> from CD, and then change it back (it’s a mentality issue…
> can’t be helped)
>
> Regards,
> --PA
>
>
> —
> 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
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
On Mon, Jan 19, 2009 at 9:06 PM, Martin O’Brien
wrote:
> This is some of the worst advice I’ve ever seen posted here. As Don
> already mentioned, if the system is configured to ‘require’ the file, you’re
> not going to be able to boot.
If you are going to delete a file, then you can also check the registry
configuration too for checking if it is a boot driver or not. Off course you
need to reverse engineer the registry which changes from one Windows version
to another.
Well I would say this reverse engineering thing only makes Anti Virus
Products viable in market.
You can’t fight a modern thief with all old rules, some times you also need
to break some rules by making sure that it will not break the system.
>
>
> I’ll give it one last try - the only thing that you, I or anyone else can
> safely do in a situation like this is reinstall Windows. Even if you wrote
> something that removed the particular file safely, once a system has been
> compromised, there really is no reasonable way (if at all, depending on how
> you analyze it) to determine the extent to which it has been compromised,
> and if you include data in this evaluation, there’s no way. In addition, I
> don’t mean this critically, but you clearly are new to all of this, and as
> with everyone who’s new, you don’t know what you’re doing, so you really and
> truly have absolutely no chance of getting this to work in a profitable time
> frame. Whatever time you envision saving with this method v. reinstalling
> the 2500 machines will not materialize, and what you will end up with is
> 2500 machines that you have to debug remotely, and I’m guessing you don’t
> know how to use windbg, which in and of itself, is a total deal breaker, and
> would keep you busy for at least the next three months, and in the end,
> you’re still going to have to reinstall windows everywhere.
>
> mm
>
>
> Deepak Gupta wrote:
>
>> I don’t know whether this malware is sitting into your File System stack
>> or storage stack or not.
>>
>> But one solution is not delete the file. Just try to corrupt it by
>> obfuscating it’s PE header.
>> To do this, try doing a raw disk read/write (again it has been discussed
>> many times on the list as a dangerous practice)
>> Obviously it will be a riskier job to do on end user’s machine (So before
>> corrupting it, take a back up of it at your quarantine location)
>>
>> After you have corrupted it, Windows will not load it and on next boot you
>> can delete it.
>>
>> Regards
>> Deepak
>>
>> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. >> xxxxx@fastmail.fm>> wrote:
>>
>> Maxim S. Shatskih wrote:
>>
>> The problem is do it in 2500 computers
>>
>>
>> Booting each machine off proper CD is the simplest possible thing.
>>
>> Preparing a proper WinPE CD with a proper script is 10-20 times
>> easier then develop the filter driver, test it and deploy on
>> 2500 machines.
>>
>>
>> Can it be done this way:
>> the native executable or driver reboots from the WinPE/BartPE/Linux CD
>> (after checking that it is the correct CD)
>> then the cleanup app that runs from the CD will remove the former,
>> so the next boot from the hard disk will go as usual.
>>
>> The procedure will be as easy for the users as possible:
>>
>> 1. Deliver the CD to users, or instruct them to burn the CD.
>> 2. Instruct the user to install something from that CD
>> ( this will cause reboot from the cd on the next boot)
>> 3. Reboot with the CD inserted
>>
>> This will spare them from discovering in the BIOS how to boot from
>> CD, and then change it back (it’s a mentality issue… can’t be helped)
>>
>> Regards,
>> --PA
>>
>>
>> —
>> 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
>
On Tue, Jan 20, 2009 at 12:45 AM, Martin O’Brien
wrote:
> And you wouldn’t even need to write a native application to do this - just
> add an entry to
>
> HKEY_LOCAL_MACHINE\System\Control\CurrentControlSet\Session
> Manager\FileRenameOperations
>
> It won’t work, but if he wants to go this route, he could at least just do
> this and see that it doesn’t work.
These are very old solutions and won’t work with the problems of OP.
Cheers
Deepak
>
>
> mm
>
>
>
>
> Deepak Gupta wrote:
>
>>
>>
>> On Mon, Jan 19, 2009 at 6:50 PM, Samir Sousa >> xxxxx@hotmail.com>> wrote:
>>
>> Have any way to do this in NT Native Api?
>>
>>
>> Native Applications come very late in system initialization order.
>> So if a driver component is there which is loading early in boot order,
>> then there is no use of having a native application deleting those files.
>>
>> Cheers
>> Deepak
>>
>> Regards.
>>
>> From: Deepak Gupta mailto:xxxxx
>> Sent: Monday, January 19, 2009 9:52 AM
>> To: Windows System Software Devs Interest List
>> mailto:xxxxx
>> Subject: Re: [ntdev] Change boot driver process.
>>
>> I don’t know whether this malware is sitting into your File System
>> stack or storage stack or not.
>>
>> But one solution is not delete the file. Just try to corrupt it by
>> obfuscating it’s PE header.
>> To do this, try doing a raw disk read/write (again it has been
>> discussed many times on the list as a dangerous practice)
>> Obviously it will be a riskier job to do on end user’s machine (So
>> before corrupting it, take a back up of it at your quarantine location)
>>
>> After you have corrupted it, Windows will not load it and on next
>> boot you can delete it.
>>
>> Regards
>> Deepak
>>
>> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. >> mailto:xxxxx> wrote:
>>
>> Maxim S. Shatskih wrote:
>>
>> The problem is do it in 2500 computers
>>
>>
>> Booting each machine off proper CD is the simplest possible
>> thing.
>>
>> Preparing a proper WinPE CD with a proper script is 10-20
>> times easier then develop the filter driver, test it and
>> deploy on 2500 machines.
>>
>>
>> Can it be done this way:
>> the native executable or driver reboots from the
>> WinPE/BartPE/Linux CD
>> (after checking that it is the correct CD)
>> then the cleanup app that runs from the CD will remove the
>> former, so the next boot from the hard disk will go as usual.
>>
>> The procedure will be as easy for the users as possible:
>>
>> 1. Deliver the CD to users, or instruct them to burn the CD.
>> 2. Instruct the user to install something from that CD
>> ( this will cause reboot from the cd on the next boot)
>> 3. Reboot with the CD inserted
>>
>> This will spare them from discovering in the BIOS how to boot
>> from CD, and then change it back (it’s a mentality issue…
>> can’t be helped)
>>
>> Regards,
>> --PA
>>
>>
>> —
>> 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
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Absolutely; that’s what I was getting at when I said ‘It won’t work.’
mm
Deepak Gupta wrote:
On Tue, Jan 20, 2009 at 12:45 AM, Martin O’Brien
> wrote:
>
> And you wouldn’t even need to write a native application to do this
> - just add an entry to
>
> HKEY_LOCAL_MACHINE\System\Control\CurrentControlSet\Session
> Manager\FileRenameOperations
>
> It won’t work, but if he wants to go this route, he could at least
> just do this and see that it doesn’t work.
>
>
> These are very old solutions and won’t work with the problems of OP.
>
> Cheers
> Deepak
>
>
>
> mm
>
>
>
>
> Deepak Gupta wrote:
>
>
>
> On Mon, Jan 19, 2009 at 6:50 PM, Samir Sousa
>
> mailto:xxxxx>>
> wrote:
>
> Have any way to do this in NT Native Api?
>
>
> Native Applications come very late in system initialization order.
> So if a driver component is there which is loading early in boot
> order, then there is no use of having a native application
> deleting those files.
>
> Cheers
> Deepak
>
> Regards.
>
> From: Deepak Gupta mailto:xxxxx> mailto:xxxxx>
> Sent: Monday, January 19, 2009 9:52 AM
>
> To: Windows System Software Devs Interest List
> mailto:xxxxx>
> Subject: Re: [ntdev] Change boot driver process.
>
>
> I don’t know whether this malware is sitting into your File
> System
> stack or storage stack or not.
>
> But one solution is not delete the file. Just try to corrupt
> it by
> obfuscating it’s PE header.
> To do this, try doing a raw disk read/write (again it has been
> discussed many times on the list as a dangerous practice)
> Obviously it will be a riskier job to do on end user’s
> machine (So
> before corrupting it, take a back up of it at your quarantine
> location)
>
> After you have corrupted it, Windows will not load it and on next
> boot you can delete it.
>
> Regards
> Deepak
>
> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A.
>
> mailto:xxxxx>> wrote:
>
> Maxim S. Shatskih wrote:
>
> The problem is do it in 2500 computers
>
>
> Booting each machine off proper CD is the simplest
> possible
> thing.
>
> Preparing a proper WinPE CD with a proper script is 10-20
> times easier then develop the filter driver, test it and
> deploy on 2500 machines.
>
>
> Can it be done this way:
> the native executable or driver reboots from the
> WinPE/BartPE/Linux CD
> (after checking that it is the correct CD)
> then the cleanup app that runs from the CD will remove the
> former, so the next boot from the hard disk will go as usual.
>
> The procedure will be as easy for the users as
> possible:
>
> 1. Deliver the CD to users, or instruct them to burn the CD.
> 2. Instruct the user to install something from that CD
> ( this will cause reboot from the cd on the next boot)
> 3. Reboot with the CD inserted
>
> This will spare them from discovering in the BIOS how to boot
> from CD, and then change it back (it’s a mentality issue…
> can’t be helped)
>
> Regards,
> --PA
>
>
> —
> 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
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Although I wasn’t really talking about the technical merit or lack there
of your proposal, with the full details, it’s even worse advice.
First, the checking the registry does not help you. Given that he wants
to write a native application, plug and play could render that value
meaningless, there are well known ways to load a driver that doesn’t
have a registry entry, and it still suffers from the same basic problem
that is unavoidable - it could all be compromised, falsified, et. c.,
and if it’s ahead of you by any of those means, you’re still not going
to be able to boot.
I agree with 100% that there are indeed situations where you have to do
the best you can. I said this a few posts ago, but I also qualified it
as there being nothing ‘generic’ about it, and also that it had to be
profitable to do so. What he would be attempting would be more
‘unknown’ than ‘generic,’ and it damn sure wouldn’t be profitable for
him or anyone else to do so, under his conditions. Either way, I’m not
sure that I would call what you suggested ‘thinking out the box;’ it’s
just not a good idea.
Similarly, the only thing that makes AV’s viable is that they are
profitable, because otherwise, they most certainly do not do good things
to system stability, they don’t exactly feature a high success rate,
which is what it is on a server, but on the desktop, given all that, the
recurring direct cost, and the huge indirect costs from having to
replace otherwise serviceable with new machines just to run an A/V, and
that AV are subject to exactly the same moving target problem, but on
steroids, they make no sense to me.
Incidentally, how this guy’s AV working out for him?
None of these are the major reason why I think your advice is awful.
Let’s assume that there are no other problems with the feasibility of
what you’re proposing. Nevertheless, if I understand your correctly,
you’re suggesting that someone who appears to know close to nothing
about windows drivers, reverse engineer the registry, develop a driver
based on this information, learn how to use windbg, debug it, then
deploy it to 2500 machines around the world, where he can’t do anything
about the problems that it will create, except reinstall the os? You’re
saying that is a more profitable solution that reinstalling the OS?
That’s why I think it’s terrible advice, and that you continue to feed
it to him is really not helping him out, in my opinion.
mm
Deepak Gupta wrote:
On Mon, Jan 19, 2009 at 9:06 PM, Martin O’Brien
> wrote:
>
> This is some of the worst advice I’ve ever seen posted here. As Don
> already mentioned, if the system is configured to ‘require’ the
> file, you’re not going to be able to boot.
>
>
> If you are going to delete a file, then you can also check the registry
> configuration too for checking if it is a boot driver or not. Off course
> you need to reverse engineer the registry which changes from one Windows
> version to another.
> Well I would say this reverse engineering thing only makes Anti Virus
> Products viable in market.
> You can’t fight a modern thief with all old rules, some times you also
> need to break some rules by making sure that it will not break the system.
>
>
>
> I’ll give it one last try - the only thing that you, I or anyone
> else can safely do in a situation like this is reinstall Windows.
> Even if you wrote something that removed the particular file
> safely, once a system has been compromised, there really is no
> reasonable way (if at all, depending on how you analyze it) to
> determine the extent to which it has been compromised, and if you
> include data in this evaluation, there’s no way. In addition, I
> don’t mean this critically, but you clearly are new to all of this,
> and as with everyone who’s new, you don’t know what you’re doing, so
> you really and truly have absolutely no chance of getting this to
> work in a profitable time frame. Whatever time you envision saving
> with this method v. reinstalling the 2500 machines will not
> materialize, and what you will end up with is 2500 machines that you
> have to debug remotely, and I’m guessing you don’t know how to use
> windbg, which in and of itself, is a total deal breaker, and would
> keep you busy for at least the next three months, and in the end,
> you’re still going to have to reinstall windows everywhere.
>
> mm
>
>
> Deepak Gupta wrote:
>
> I don’t know whether this malware is sitting into your File
> System stack or storage stack or not.
>
> But one solution is not delete the file. Just try to corrupt it
> by obfuscating it’s PE header.
> To do this, try doing a raw disk read/write (again it has been
> discussed many times on the list as a dangerous practice)
> Obviously it will be a riskier job to do on end user’s machine
> (So before corrupting it, take a back up of it at your
> quarantine location)
>
> After you have corrupted it, Windows will not load it and on
> next boot you can delete it.
>
> Regards
> Deepak
>
> On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. > mailto:xxxxx mailto:xxxxx> mailto:xxxxx>> wrote:
>
> Maxim S. Shatskih wrote:
>
> The problem is do it in 2500 computers
>
>
> Booting each machine off proper CD is the simplest
> possible thing.
>
> Preparing a proper WinPE CD with a proper script is 10-20
> times
> easier then develop the filter driver, test it and deploy on
> 2500 machines.
>
>
> Can it be done this way:
> the native executable or driver reboots from the
> WinPE/BartPE/Linux CD
> (after checking that it is the correct CD)
> then the cleanup app that runs from the CD will remove the
> former,
> so the next boot from the hard disk will go as usual.
>
> The procedure will be as easy for the users as possible:
>
> 1. Deliver the CD to users, or instruct them to burn the CD.
> 2. Instruct the user to install something from that CD
> ( this will cause reboot from the cd on the next boot)
> 3. Reboot with the CD inserted
>
> This will spare them from discovering in the BIOS how to boot
> from
> CD, and then change it back (it’s a mentality issue… can’t
> be helped)
>
> Regards,
> --PA
>
>
> —
> 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
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
“Deepak Gupta” wrote in message news:xxxxx@ntdev…
> You can’t fight a modern thief with all old rules, some times you also
> need
> to break some rules by making sure that it will not break the system.
>
But more importantly you cannot fight anyone well if you assume as the OP
does that the opponent is not smarter, sneakier, and in general better than
you. I’ve seen too many people in the AV world take the attitude we are
smart so we will win, and their products become malware vectors rather than
fighters.
–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
I don’t understand why it is even a question of intelligence or
competence. This whole attempt is futile from a systems-theoretical
viewpoint.
On Mon, 19 Jan 2009 21:03:36 +0100, Don Burn wrote:
> “Deepak Gupta” wrote in message
> news:xxxxx@ntdev…
>> You can’t fight a modern thief with all old rules, some times you also
>> need
>> to break some rules by making sure that it will not break the system.
>>
> But more importantly you cannot fight anyone well if you assume as the OP
> does that the opponent is not smarter, sneakier, and in general better
> than
> you. I’ve seen too many people in the AV world take the attitude we are
> smart so we will win, and their products become malware vectors rather
> than
> fighters.
So in this case, have a way to put my driver before the trojan driver?
Regards.
From: Deepak Gupta
Sent: Monday, January 19, 2009 5:11 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Change boot driver process.
On Mon, Jan 19, 2009 at 6:50 PM, Samir Sousa wrote:
Have any way to do this in NT Native Api?
Native Applications come very late in system initialization order.
So if a driver component is there which is loading early in boot order, then there is no use of
having a native application deleting those files.
Cheers
Deepak
Regards.
From: Deepak Gupta
Sent: Monday, January 19, 2009 9:52 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Change boot driver process.
I don’t know whether this malware is sitting into your File System stack or storage stack or not.
But one solution is not delete the file. Just try to corrupt it by obfuscating it’s PE header.
To do this, try doing a raw disk read/write (again it has been discussed many times on the list as a dangerous practice)
Obviously it will be a riskier job to do on end user’s machine (So before corrupting it, take a back up of it at your quarantine location)
After you have corrupted it, Windows will not load it and on next boot you can delete it.
Regards
Deepak
On Mon, Jan 19, 2009 at 3:31 PM, Pavel A. wrote:
Maxim S. Shatskih wrote:
The problem is do it in 2500 computers
Booting each machine off proper CD is the simplest possible thing.
Preparing a proper WinPE CD with a proper script is 10-20 times easier then develop the filter driver, test it and deploy on 2500 machines.
Can it be done this way:
the native executable or driver reboots from the WinPE/BartPE/Linux CD
(after checking that it is the correct CD)
then the cleanup app that runs from the CD will remove the former, so the next boot from the hard disk will go as usual.
The procedure will be as easy for the users as possible:
1. Deliver the CD to users, or instruct them to burn the CD.
2. Instruct the user to install something from that CD
( this will cause reboot from the cd on the next boot)
3. Reboot with the CD inserted
This will spare them from discovering in the BIOS how to boot from CD, and then change it back (it’s a mentality issue… can’t be helped)
Regards,
--PA
—
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
Samir Sousa wrote:
So in this case, have a way to put my driver before the trojan driver?
No. Repeating myself, whatever you do, they can undo.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.