Re: SysHook and STATUS_ACCESS_VIOLATION
- From: "James Antognini [MSFT]" <jantogni@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 5 Jul 2005 18:43:26 -0700
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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7ADD1394-BF8E-4D27-90BC-D11D2EB2B443@xxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:AB947984-AF43-4E58-9983-D7CA2DA95F09@xxxxxxxxxxxxxxxx
>> > 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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> news:33BC9768-26F5-4DA4-9BF5-86C24FA929F4@xxxxxxxxxxxxxxxx
>> >> > 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
>> >>
>> >>
>> >>
>>
>>
>>
.
- References:
- SysHook and STATUS_ACCESS_VIOLATION
- From: Gian-Luca
- Re: SysHook and STATUS_ACCESS_VIOLATION
- From: Don Burn
- Re: SysHook and STATUS_ACCESS_VIOLATION
- From: Gian-Luca
- Re: SysHook and STATUS_ACCESS_VIOLATION
- From: Don Burn
- Re: SysHook and STATUS_ACCESS_VIOLATION
- From: Gian-Luca
- SysHook and STATUS_ACCESS_VIOLATION
- Prev by Date: driver image path
- Next by Date: Re: [Audio Driver] - Volume Control
- Previous by thread: Re: SysHook and STATUS_ACCESS_VIOLATION
- Next by thread: Re: DPC/ISR synchronization (windows ce)
- Index(es):
Relevant Pages
|
