Prev: "windows error recovery" tigger in Win7?
Next: Problem with getting handle to a device
From: sarshah20 on 13 Apr 2010 07:24
Thanks everyone for your response.

Jonathan: Thanks for you suggestion. Calling the documented APIs in
the ordinary way wont work here. They are already hooked by the
malware.


Don: Thats a better idea to use IoCreateFile (filter drivers). Is
there anything similar i can use for process and registry?


sarshah.

The response i posted earlier did not appear in this group.



On Apr 10, 6:43 am, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...(a)NTLWorld.COM> wrote:
> > Consider the scenario where SSDT is modified by a malware and
> > important calls are hooked. I calculate original system routine
> > addresses from ntoskernl.exe.
>
> In other words, you're doing the very same thing as the malware did, and
> in addition you are adding yet another Heath Robinson mechanism to the
> kernel that will complicate everyone's lives just that little bit
> further when they have to work out why your driver's behaviour differs
> from the behaviour of the rest of the system.  You are not in the
> business of creating customer support nightmares for the world.  Stop
> trying to.  Call the documented APIs that are provided to you, in the
> ordinary way.

From: rogero on 13 Apr 2010 09:07
On Apr 13, 12:24 pm, sarsha...(a)yahoo.com wrote:
> Thanks everyone for your response.
>
> Jonathan: Thanks for you suggestion. Calling the documented APIs in
> the ordinary way wont work here. They are already hooked by the
> malware.
>
> Don: Thats a better idea to use IoCreateFile (filter drivers). Is
> there anything similar i can use for process and registry?

Can you explain what you are trying to accomplish?

If you have malware *whatever* mechanism you try to use
might be hooked.

Roger.
From: sarshah20 on 14 Apr 2010 06:20
Thanks Roger. For now, i just want to be able to cleanly call a system
routine even if it is hooked. At this stage i want control at user
space (create, add, delete file/process/reg) and i did not want to
hook anything at user space. Therefore, using SSDT seemed like a good
idea. For future, i would prefer to go to a filter driver for files as
suggested earlier.

About the hooking, yes malware could go to any level. I already have
this info available (through some mechanism) about a software/malware
so it can be dealt with.

sarshah

On Apr 13, 6:07 pm, rogero <roger....(a)gmail.com> wrote:
> On Apr 13, 12:24 pm, sarsha...(a)yahoo.com wrote:
>
> > Thanks everyone for your response.
>
> > Jonathan: Thanks for you suggestion. Calling the documented APIs in
> > the ordinary way wont work here. They are already hooked by the
> > malware.
>
> > Don: Thats a better idea to use IoCreateFile (filter drivers). Is
> > there anything similar i can use for process and registry?
>
> Can you explain what you are trying to accomplish?
>
> If you have malware *whatever* mechanism you try to use
> might be hooked.
>
> Roger.

From: Alexander Grigoriev on 14 Apr 2010 10:19
Another project not solving no-problem.

If you accept that kernel routines can be hooked by malware, you've already
lost the battle. The only way to clean it is to wipe everything.

I wish the people understood that the only way to protect the OS is not to
give an user administrative rights, and not run untrusted code with high
privileges.

<sarshah20(a)yahoo.com> wrote in message
news:52176d6c-948e-4264-a5d5-7ad18d255363(a)z11g2000yqz.googlegroups.com...
Thanks Roger. For now, i just want to be able to cleanly call a system
routine even if it is hooked. At this stage i want control at user
space (create, add, delete file/process/reg) and i did not want to
hook anything at user space. Therefore, using SSDT seemed like a good
idea. For future, i would prefer to go to a filter driver for files as
suggested earlier.

About the hooking, yes malware could go to any level. I already have
this info available (through some mechanism) about a software/malware
so it can be dealt with.

sarshah

On Apr 13, 6:07 pm, rogero <roger....(a)gmail.com> wrote:
> On Apr 13, 12:24 pm, sarsha...(a)yahoo.com wrote:
>
> > Thanks everyone for your response.
>
> > Jonathan: Thanks for you suggestion. Calling the documented APIs in
> > the ordinary way wont work here. They are already hooked by the
> > malware.
>
> > Don: Thats a better idea to use IoCreateFile (filter drivers). Is
> > there anything similar i can use for process and registry?
>
> Can you explain what you are trying to accomplish?
>
> If you have malware *whatever* mechanism you try to use
> might be hooked.
>
> Roger.


From: Jonathan de Boyne Pollard on 14 Apr 2010 12:35
>
>>>
>>> Consider the scenario where SSDT is modified by a malware and
>>> important calls are hooked. I calculate original system routine
>>> addresses from ntoskernl.exe.
>>>
>> In other words, you're doing the very same thing as the malware did,
>> and in addition you are adding yet another Heath Robinson mechanism
>> to the kernel that will complicate everyone's lives just that little
>> bit further when they have to work out why your driver's behaviour
>> differs from the behaviour of the rest of the system. You are not in
>> the business of creating customer support nightmares for the world.
>> Stop trying to. Call the documented APIs that are provided to you,
>> in the ordinary way.
>>
> Thanks for you suggestion. Calling the documented APIs in the ordinary
> way won't work here. They are already hooked by the malware.
>
Only when there is malware present in the first place. And if there is,
it's not the business of some random device driver to try to fight
that. Leave Heath Robinson mechanisms out of the kernel that complicate
everyone's lives and cause customer support nightmares. The world really
does not want to have to work out why your device driver is fighting
with their anti-malware tools, or is reported as malware in its own
right by such tools, or breaks on different releases of the operating
system. Call the documented APIs that are provided to you, in the
ordinary way, and concentrate upon driving your device instead of adding
more rickety contraptions and unexpected interactions to kernel mode.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: "windows error recovery" tigger in Win7?
Next: Problem with getting handle to a device