Prev: DrvQueryFontTree fails with Splwow64.exe
Next: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL
From: Don Burn on 1 Jul 2005 11:29
Comments inline:

From: "Gian-Luca" <GianLuca(a)discussions.microsoft.com>


> First:
> research.microsoft.com/sn/detours/

First unless you have licensed revision 2.0 this was for research only in
part because the was recognition of problems. Note the quote about 2.0
"Detours is a library for instrumenting arbitrary Win32 functions on x86
machines. Detours intercepts Win32 functions by re-writing target function
images." Hmm, since when is the kernel 2.0. Finally note that Detours
uses a different hooking mechanism.

> 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);
>
> }

Be aware this will not work on 64-bit windows, and as I noted before you
have a limited set of calls that you can extract the data from.

> 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.

Well that does seem to prove that you have done something wrong with your
MyZwopenkey, I would say get to work debugging.

> The FileMon,RegMon,etc. use this way to work. Try to disassemble the .sys
> on
> the exe (it is a resource of the exe)

Filemon has always been a file system filter driver and never used hooking.
RegMon did use hooking but changed to support newer OS'es to use the Cm
calls.


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



From: JohnG on 1 Jul 2005 11:42
Hi,

In answer to your orginal question, I think the problem is that you cannot
pass addresses to memory allocated in kernel. The kernel function is
expecting the address to be within the user-mode virtual address space. You
need to allocate memory from user-mode address space and use this when
passing to the function. ZwAllocateVirtualMemory() should help.

John.

"Gian-Luca" wrote:

> 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
> > >>
> > >>
> > >>
> >
> >
> >
From: Gian-Luca on 4 Jul 2005 03:00
Hi JohnG

and thank's for your answer.

Before posting my problem on this newsgroup, I've tryed to use the
ZwAllocateVirtualMemory(), but it din't work.
this is the code:

Size=sizeof(UNICODE_STRING);
ntstatus
=ZwAllocateVirtualMemory(NtCurrentProcess(),&pObjAttr,0,&Size,MEM_COMMIT,PAGE_READWRITE);
DbgPrint(("ZwAllocateVirtualMemory(%X) pObjAttr=%08X Size=%08X\n",
ntstatus,pObjAttr,Size));
RtlCopyMemory(&((PCHAR)pObjAttr)[sizeof(UNICODE_STRING)],L"\\REGISTRY\\MACHINE\\SOFTWARE\\MICROSOFT",(wcslen(L"\\REGISTRY\\MACHINE\\SOFTWARE\\MICROSOFT")+1)*sizeof(WCHAR));
RtlInitUnicodeString(((PUNICODE_STRING)pObjAttr),(PCWSTR)(&((PCHAR)pObjAttr)[sizeof(UNICODE_STRING)]));

After ZwAllocateVirtualMemory the value of Size was 0x1000 so I've copied
the redirected value of registry just after the UNICODE_STRING area.

I've used an invalid parameter for ZwAllocateVirtualMemory?

Thank's

Gianluca


"JohnG" wrote:

> Hi,
>
> In answer to your orginal question, I think the problem is that you cannot
> pass addresses to memory allocated in kernel. The kernel function is
> expecting the address to be within the user-mode virtual address space. You
> need to allocate memory from user-mode address space and use this when
> passing to the function. ZwAllocateVirtualMemory() should help.
>
> John.
>
> "Gian-Luca" wrote:
>
> > 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
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
From: Gian-Luca on 4 Jul 2005 03:25
Instead of a simple RtlCopyMemory, I've to use th ZwWriteVirtualMemory() but
I can't link this function, NTOSKRNL.exe have only the
ZwAllocateVitualMemory() Function.

"Gian-Luca" wrote:

> Hi JohnG
>
> and thank's for your answer.
>
> Before posting my problem on this newsgroup, I've tryed to use the
> ZwAllocateVirtualMemory(), but it din't work.
> this is the code:
>
> Size=sizeof(UNICODE_STRING);
> ntstatus
> =ZwAllocateVirtualMemory(NtCurrentProcess(),&pObjAttr,0,&Size,MEM_COMMIT,PAGE_READWRITE);
> DbgPrint(("ZwAllocateVirtualMemory(%X) pObjAttr=%08X Size=%08X\n",
> ntstatus,pObjAttr,Size));
> RtlCopyMemory(&((PCHAR)pObjAttr)[sizeof(UNICODE_STRING)],L"\\REGISTRY\\MACHINE\\SOFTWARE\\MICROSOFT",(wcslen(L"\\REGISTRY\\MACHINE\\SOFTWARE\\MICROSOFT")+1)*sizeof(WCHAR));
> RtlInitUnicodeString(((PUNICODE_STRING)pObjAttr),(PCWSTR)(&((PCHAR)pObjAttr)[sizeof(UNICODE_STRING)]));
>
> After ZwAllocateVirtualMemory the value of Size was 0x1000 so I've copied
> the redirected value of registry just after the UNICODE_STRING area.
>
> I've used an invalid parameter for ZwAllocateVirtualMemory?
>
> Thank's
>
> Gianluca
>
>
> "JohnG" wrote:
>
> > Hi,
> >
> > In answer to your orginal question, I think the problem is that you cannot
> > pass addresses to memory allocated in kernel. The kernel function is
> > expecting the address to be within the user-mode virtual address space. You
> > need to allocate memory from user-mode address space and use this when
> > passing to the function. ZwAllocateVirtualMemory() should help.
> >
> > John.
> >
> > "Gian-Luca" wrote:
> >
> > > 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
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
From: James Antognini [MSFT] on 5 Jul 2005 21:43
Updating OS kernel or OS service binaries isn't supported. Period.

The detours package shows a technique. Fine. Applying that technique to the
OS kernel or OS services is a different matter. Updating OS kernel or OS
service binaries isn't supported. Period.

Now if you want to update or otherwise hook in your private laboratory,
great. If you distribute such code to others and if the something breaks for
them or you, there will be no support.

That aside, there are some technical issues, such as what Don pointed out.

--
James Antognini
Windows DDK Support


This posting is provided "AS IS" with no warranties, and confers no rights.



"Gian-Luca" <GianLuca(a)discussions.microsoft.com> wrote in message
news:7ADD1394-BF8E-4D27-90BC-D11D2EB2B443(a)microsoft.com...
> 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
>> >>
>> >>
>> >>
>>
>>
>>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: DrvQueryFontTree fails with Splwow64.exe
Next: Please HELP - Analyzing IRQL_NOT_LESS_OR_EQUAL