Prev: DrvQueryFontTree fails with Splwow64.exe
Next: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL
From: Gian-Luca on 1 Jul 2005 09:07
Hi,

Recently I've attempt to write a driver in order to hook any registry access
using the KeServiceDescriptorTable and then subst the table entry with my
function.
If I use the this code only for logging (ie. RegMon) it's all ok, but if I
try to modify the parameter all the Zwxx function give me a
STATUS_ACCESS_VIOLATION:

for example:

- if the key that the application want to open is
\Registry\Machine\Software\Test
I create (ExAllocatePool) a new POBJECT_ATTRIBUTES and relative
PUNICODE_STRING

- then I call the RealZwOpenKey (the real KeServiceDescriptorTable's function)

but If I do so the function give me the error.

But, If I dehook the ZwOpenKey and the I call ZwOpenKey the Fn is Ok.
But dehooking this Fn isn't good (some access could be lost).

It seems that the real ZwOpenKey's code can't or don't want access the
memory allocated by the driver...

thank's
From: Don Burn on 1 Jul 2005 09:24
First any system hooking is STUPID, it is likely to crash the system.
Second, registry hooking is REALLY STUPID since there are callback routines
(see CmRegisterCallback) that provide a mechanism for supporting this stuff.


If you want to do this, at least give us enough data to show what could be
wrong. You state you allocate memory, in what pool? How did you set up
your OBJECT_ATTRIBUTE structure, etc.

As a final request, as I ask for all IDIOTS who do something as REALLY
REALLY STUPID AS HOOKING, please tell us your company and product, so we can
be sure to avoid it at all costs.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
news:33BC9768-26F5-4DA4-9BF5-86C24FA929F4(a)microsoft.com...
> Hi,
>
> Recently I've attempt to write a driver in order to hook any registry
> access
> using the KeServiceDescriptorTable and then subst the table entry with my
> function.
> If I use the this code only for logging (ie. RegMon) it's all ok, but if I
> try to modify the parameter all the Zwxx function give me a
> STATUS_ACCESS_VIOLATION:
>
> for example:
>
> - if the key that the application want to open is
> \Registry\Machine\Software\Test
> I create (ExAllocatePool) a new POBJECT_ATTRIBUTES and relative
> PUNICODE_STRING
>
> - then I call the RealZwOpenKey (the real KeServiceDescriptorTable's
> function)
>
> but If I do so the function give me the error.
>
> But, If I dehook the ZwOpenKey and the I call ZwOpenKey the Fn is Ok.
> But dehooking this Fn isn't good (some access could be lost).
>
> It seems that the real ZwOpenKey's code can't or don't want access the
> memory allocated by the driver...
>
> thank's


From: Gian-Luca on 1 Jul 2005 10:10
Dear Don,

thank's for your beautifull answer ;)

I've decided to use Hooking for some reasons:

- My company is specialized to make application, born to be single client,
working in a Terminal server env

- Hooking is the only (an suggested by your colleagues) way to do this, and
the MS is selling a library to do this

- Ms Hooking's Library is not ok, because cuold create a series of bug
(tested by me)

- In order to make our SW working in the best manner, I'm testing the Device
driver's way

- I've to hook other Zw Function (ZwopenKey was only an example), Windows
has callback for other Zw?

and finally, from IFS Help (about CmRegisterCallback):

"...This routine is available on Microsoft Windows XP and later operating
systems.."

and even if MS would let die win2000, our's customers have it on their
server ;)
XP, 2003 and longhorn have a big LIVING father.

So, before write so much STUPID, probably you have to listen my answer, ok?

If you can answer me, I'll give you all the info you asked.

Thank's anyway.

"Don Burn" wrote:

> First any system hooking is STUPID, it is likely to crash the system.
> Second, registry hooking is REALLY STUPID since there are callback routines
> (see CmRegisterCallback) that provide a mechanism for supporting this stuff.
>
>
> If you want to do this, at least give us enough data to show what could be
> wrong. You state you allocate memory, in what pool? How did you set up
> your OBJECT_ATTRIBUTE structure, etc.
>
> As a final request, as I ask for all IDIOTS who do something as REALLY
> REALLY STUPID AS HOOKING, please tell us your company and product, so we can
> be sure to avoid it at all costs.
>
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> "Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
> news:33BC9768-26F5-4DA4-9BF5-86C24FA929F4(a)microsoft.com...
> > Hi,
> >
> > Recently I've attempt to write a driver in order to hook any registry
> > access
> > using the KeServiceDescriptorTable and then subst the table entry with my
> > function.
> > If I use the this code only for logging (ie. RegMon) it's all ok, but if I
> > try to modify the parameter all the Zwxx function give me a
> > STATUS_ACCESS_VIOLATION:
> >
> > for example:
> >
> > - if the key that the application want to open is
> > \Registry\Machine\Software\Test
> > I create (ExAllocatePool) a new POBJECT_ATTRIBUTES and relative
> > PUNICODE_STRING
> >
> > - then I call the RealZwOpenKey (the real KeServiceDescriptorTable's
> > function)
> >
> > but If I do so the function give me the error.
> >
> > But, If I dehook the ZwOpenKey and the I call ZwOpenKey the Fn is Ok.
> > But dehooking this Fn isn't good (some access could be lost).
> >
> > It seems that the real ZwOpenKey's code can't or don't want access the
> > memory allocated by the driver...
> >
> > thank's
>
>
>
From: Don Burn on 1 Jul 2005 10:38
Excuse me you claim Microsoft has a hooking library, since when? The Cm
calls are built in, and work well, so if you have a bug please share it with
Microsoft, and the community. Yes, it true you have to roll you own for
Windows 2000, but at least an intelligent approach is to use the Cm calls
when available.

Now, why hooking is stupid:

1. Once you hook you can never unhook!

2. You can't rely on argument subsitution in most cases, since if you
hook you can't be sure some other driver is not hooking at the same time so
you get for call A: driver1hook->driver2hook->real but for call B:
driver2hook->driver1hook->real

3. You can't get all the hooks (even for the registry) without using a
use space component which makes hooking worse since you have to hook well
into the startup process.

4. Hooking will not work on all platforms.


Now, I did ask some questions about your code to try to help you, but
apparently you didn't want to answer. I or others on this group can't help
you with you symptom, without the answers to the questions that will at
least give us some idea of what is wrong.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply


"Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
news:AB947984-AF43-4E58-9983-D7CA2DA95F09(a)microsoft.com...
> Dear Don,
>
> thank's for your beautifull answer ;)
>
> I've decided to use Hooking for some reasons:
>
> - My company is specialized to make application, born to be single client,
> working in a Terminal server env
>
> - Hooking is the only (an suggested by your colleagues) way to do this,
> and
> the MS is selling a library to do this
>
> - Ms Hooking's Library is not ok, because cuold create a series of bug
> (tested by me)
>
> - In order to make our SW working in the best manner, I'm testing the
> Device
> driver's way
>
> - I've to hook other Zw Function (ZwopenKey was only an example), Windows
> has callback for other Zw?
>
> and finally, from IFS Help (about CmRegisterCallback):
>
> "...This routine is available on Microsoft Windows XP and later operating
> systems.."
>
> and even if MS would let die win2000, our's customers have it on their
> server ;)
> XP, 2003 and longhorn have a big LIVING father.
>
> So, before write so much STUPID, probably you have to listen my answer,
> ok?
>
> If you can answer me, I'll give you all the info you asked.
>
> Thank's anyway.
>
> "Don Burn" wrote:
>
>> First any system hooking is STUPID, it is likely to crash the system.
>> Second, registry hooking is REALLY STUPID since there are callback
>> routines
>> (see CmRegisterCallback) that provide a mechanism for supporting this
>> stuff.
>>
>>
>> If you want to do this, at least give us enough data to show what could
>> be
>> wrong. You state you allocate memory, in what pool? How did you set up
>> your OBJECT_ATTRIBUTE structure, etc.
>>
>> As a final request, as I ask for all IDIOTS who do something as REALLY
>> REALLY STUPID AS HOOKING, please tell us your company and product, so we
>> can
>> be sure to avoid it at all costs.
>>
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> "Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
>> news:33BC9768-26F5-4DA4-9BF5-86C24FA929F4(a)microsoft.com...
>> > Hi,
>> >
>> > Recently I've attempt to write a driver in order to hook any registry
>> > access
>> > using the KeServiceDescriptorTable and then subst the table entry with
>> > my
>> > function.
>> > If I use the this code only for logging (ie. RegMon) it's all ok, but
>> > if I
>> > try to modify the parameter all the Zwxx function give me a
>> > STATUS_ACCESS_VIOLATION:
>> >
>> > for example:
>> >
>> > - if the key that the application want to open is
>> > \Registry\Machine\Software\Test
>> > I create (ExAllocatePool) a new POBJECT_ATTRIBUTES and relative
>> > PUNICODE_STRING
>> >
>> > - then I call the RealZwOpenKey (the real KeServiceDescriptorTable's
>> > function)
>> >
>> > but If I do so the function give me the error.
>> >
>> > But, If I dehook the ZwOpenKey and the I call ZwOpenKey the Fn is Ok.
>> > But dehooking this Fn isn't good (some access could be lost).
>> >
>> > It seems that the real ZwOpenKey's code can't or don't want access the
>> > memory allocated by the driver...
>> >
>> > thank's
>>
>>
>>


From: Gian-Luca on 1 Jul 2005 11:11
First:
research.microsoft.com/sn/detours/

now I'll give you an example of my code:


.....
NTSTATUS (*RealZwOpenKey)( IN PHANDLE, IN OUT ACCESS_MASK, IN
POBJECT_ATTRIBUTES );
extern PULONG KeServiceDescriptorTable;
#define SYSCALL(_number) ServiceTable->ServiceTable[_number]
#define SYSCALL2(_number) &ServiceTable->ServiceTable[_number]
.....

VOID Hook()
{
RealZwopenkey = SYSCALL(ulZwopenkeyCode );
InterlockedExchangePointer(SYSCALL2( FnHookulZwopenkeyCode ),MyZwopenkey);

}

NTSTATUS MyZwOpenKey( IN OUT PHANDLE pHandle, IN ACCESS_MASK ReqAccess,
IN POBJECT_ATTRIBUTES pOpenInfo )
{
NTSTATUS ntstatus;
OBJECT_ATTRIBUTES RedirOpenInfo;
UNICODE_STRING us;


RtlInitUnicodeString(&us,L"\\Registry\\machine\\software\\microsoft");
RedirOpenInfo.ObjectName=&us;
RedirOpenInfo.RootDirectory=NULL;
RedirOpenInfo.Attributes=0x40;

(zero other OBJECT_ATTRIBUTES members)

ntstatus = RealZwOpenKey( pHandle, ReqAccess, &RedirOpenInfo);

(ntstatus = 0xC0000005)

return ntstatus;

}

if I change:

....

//zero other OBJECT_ATTRIBUTES members
UnHook(ulZwOpenKeyCode);
ntstatus = ZwOpenKey( pHandle, ReqAccess, &RedirOpenInfo);
Hook(ulZwOpenKeyCode);

//ntstatus = STATUS_SUCCESS

return ntstatus;

}

tell me if you would other info.
The FileMon,RegMon,etc. use this way to work. Try to disassemble the .sys on
the exe (it is a resource of the exe)



"Don Burn" wrote:

> Excuse me you claim Microsoft has a hooking library, since when? The Cm
> calls are built in, and work well, so if you have a bug please share it with
> Microsoft, and the community. Yes, it true you have to roll you own for
> Windows 2000, but at least an intelligent approach is to use the Cm calls
> when available.
>
> Now, why hooking is stupid:
>
> 1. Once you hook you can never unhook!
>
> 2. You can't rely on argument subsitution in most cases, since if you
> hook you can't be sure some other driver is not hooking at the same time so
> you get for call A: driver1hook->driver2hook->real but for call B:
> driver2hook->driver1hook->real
>
> 3. You can't get all the hooks (even for the registry) without using a
> use space component which makes hooking worse since you have to hook well
> into the startup process.
>
> 4. Hooking will not work on all platforms.
>
>
> Now, I did ask some questions about your code to try to help you, but
> apparently you didn't want to answer. I or others on this group can't help
> you with you symptom, without the answers to the questions that will at
> least give us some idea of what is wrong.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
> "Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
> news:AB947984-AF43-4E58-9983-D7CA2DA95F09(a)microsoft.com...
> > Dear Don,
> >
> > thank's for your beautifull answer ;)
> >
> > I've decided to use Hooking for some reasons:
> >
> > - My company is specialized to make application, born to be single client,
> > working in a Terminal server env
> >
> > - Hooking is the only (an suggested by your colleagues) way to do this,
> > and
> > the MS is selling a library to do this
> >
> > - Ms Hooking's Library is not ok, because cuold create a series of bug
> > (tested by me)
> >
> > - In order to make our SW working in the best manner, I'm testing the
> > Device
> > driver's way
> >
> > - I've to hook other Zw Function (ZwopenKey was only an example), Windows
> > has callback for other Zw?
> >
> > and finally, from IFS Help (about CmRegisterCallback):
> >
> > "...This routine is available on Microsoft Windows XP and later operating
> > systems.."
> >
> > and even if MS would let die win2000, our's customers have it on their
> > server ;)
> > XP, 2003 and longhorn have a big LIVING father.
> >
> > So, before write so much STUPID, probably you have to listen my answer,
> > ok?
> >
> > If you can answer me, I'll give you all the info you asked.
> >
> > Thank's anyway.
> >
> > "Don Burn" wrote:
> >
> >> First any system hooking is STUPID, it is likely to crash the system.
> >> Second, registry hooking is REALLY STUPID since there are callback
> >> routines
> >> (see CmRegisterCallback) that provide a mechanism for supporting this
> >> stuff.
> >>
> >>
> >> If you want to do this, at least give us enough data to show what could
> >> be
> >> wrong. You state you allocate memory, in what pool? How did you set up
> >> your OBJECT_ATTRIBUTE structure, etc.
> >>
> >> As a final request, as I ask for all IDIOTS who do something as REALLY
> >> REALLY STUPID AS HOOKING, please tell us your company and product, so we
> >> can
> >> be sure to avoid it at all costs.
> >>
> >>
> >>
> >> --
> >> Don Burn (MVP, Windows DDK)
> >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> >> Remove StopSpam from the email to reply
> >>
> >>
> >>
> >> "Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
> >> news:33BC9768-26F5-4DA4-9BF5-86C24FA929F4(a)microsoft.com...
> >> > Hi,
> >> >
> >> > Recently I've attempt to write a driver in order to hook any registry
> >> > access
> >> > using the KeServiceDescriptorTable and then subst the table entry with
> >> > my
> >> > function.
> >> > If I use the this code only for logging (ie. RegMon) it's all ok, but
> >> > if I
> >> > try to modify the parameter all the Zwxx function give me a
> >> > STATUS_ACCESS_VIOLATION:
> >> >
> >> > for example:
> >> >
> >> > - if the key that the application want to open is
> >> > \Registry\Machine\Software\Test
> >> > I create (ExAllocatePool) a new POBJECT_ATTRIBUTES and relative
> >> > PUNICODE_STRING
> >> >
> >> > - then I call the RealZwOpenKey (the real KeServiceDescriptorTable's
> >> > function)
> >> >
> >> > but If I do so the function give me the error.
> >> >
> >> > But, If I dehook the ZwOpenKey and the I call ZwOpenKey the Fn is Ok.
> >> > But dehooking this Fn isn't good (some access could be lost).
> >> >
> >> > It seems that the real ZwOpenKey's code can't or don't want access the
> >> > memory allocated by the driver...
> >> >
> >> > thank's
> >>
> >>
> >>
>
>
>
 |  Next  |  Last
Pages: 1 2 3
Prev: DrvQueryFontTree fails with Splwow64.exe
Next: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL