Hi,
I have a question with respect to accessing the system service dispatch
table on win2k drivers.
I am trying to access the SSDT structure exposed by NTOSKRNL as
KeServiceDescriptorTable in my driver routine. But when I try to build the
driver it is saying that KeServiceDescriptorTable is undeclared identifier.
Pls let me know which include file I have to include to get rid of this
compiler error.
Thanks in advance…
Sankarshana M
extern “C”
{
typedef struct _SRVTABLE
{
PVOID *spServiceTable;
ULONG LowCall;
ULONG HiCall;
PVOID *ArgTable;
} SRVTABLE, *PSRVTABLE;
extern PSRVTABLE KeServiceDescriptorTable;
}
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of sankar
Sent: Thursday, November 21, 2002 12:17 PM
To: NT Developers Interest List
Subject: [ntdev] How to access KeServiceDescriptorTableHi,
I have a question with respect to accessing the system
service dispatch table on win2k drivers. I am trying to
access the SSDT structure exposed by NTOSKRNL as
KeServiceDescriptorTable in my driver routine. But when I try
to build the driver it is saying that
KeServiceDescriptorTable is undeclared identifier. Pls let me
know which include file I have to include to get rid of this
compiler error.Thanks in advance…
Sankarshana M
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%
There is no public include file that defines this private kernel object.
Perhaps you should explain what it is you are trying to do, and we could
provide some sort of legitimate method to accomplish your goal.
===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
-----Original Message-----
From: “sankar”
To: “NT Developers Interest List”
Date: Thu, 21 Nov 2002 12:16:46 -0800
Subject: [ntdev] How to access KeServiceDescriptorTable
> Hi,
> I have a question with respect to accessing the system service dispatch
> table on win2k drivers.
> I am trying to access the SSDT structure exposed by NTOSKRNL as
> KeServiceDescriptorTable in my driver routine. But when I try to build
> the
> driver it is saying that KeServiceDescriptorTable is undeclared
> identifier.
> Pls let me know which include file I have to include to get rid of this
> compiler error.
>
> Thanks in advance…
>
> Sankarshana M
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%
I am trying to hook onto windows system services for debugging purposes.
----- Original Message -----
From: “Mark Roddy”
To: “NT Developers Interest List”
Sent: Friday, November 22, 2002 6:33 AM
Subject: [ntdev] Re: How to access KeServiceDescriptorTable
> There is no public include file that defines this private kernel object.
> Perhaps you should explain what it is you are trying to do, and we could
> provide some sort of legitimate method to accomplish your goal.
>
>
> ===========================
> Mark Roddy
> Consultant, Microsoft DDK MVP
> Hollis Technology Solutions
> xxxxx@hollistech.com
> www.hollistech.com
> 603-321-1032
>
>
> -----Original Message-----
> From: “sankar”
> To: “NT Developers Interest List”
> Date: Thu, 21 Nov 2002 12:16:46 -0800
> Subject: [ntdev] How to access KeServiceDescriptorTable
>
> > Hi,
> > I have a question with respect to accessing the system service dispatch
> > table on win2k drivers.
> > I am trying to access the SSDT structure exposed by NTOSKRNL as
> > KeServiceDescriptorTable in my driver routine. But when I try to build
> > the
> > driver it is saying that KeServiceDescriptorTable is undeclared
> > identifier.
> > Pls let me know which include file I have to include to get rid of this
> > compiler error.
> >
> > Thanks in advance…
> >
> > Sankarshana M
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com
> > To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to %%email.unsub%%
>
Hooking the system services table is a very bad idea. You will probably end
up with more problems later. If you tell us what you want to debug we can
suggeste a better method.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“sankar” wrote in message news:xxxxx@ntdev…
>
> I am trying to hook onto windows system services for debugging purposes.
> ----- Original Message -----
> From: “Mark Roddy”
> To: “NT Developers Interest List”
> Sent: Friday, November 22, 2002 6:33 AM
> Subject: [ntdev] Re: How to access KeServiceDescriptorTable
>
>
> > There is no public include file that defines this private kernel object.
> > Perhaps you should explain what it is you are trying to do, and we could
> > provide some sort of legitimate method to accomplish your goal.
> >
> >
> > ===========================
> > Mark Roddy
> > Consultant, Microsoft DDK MVP
> > Hollis Technology Solutions
> > xxxxx@hollistech.com
> > www.hollistech.com
> > 603-321-1032
> >
> >
> > -----Original Message-----
> > From: “sankar”
> > To: “NT Developers Interest List”
> > Date: Thu, 21 Nov 2002 12:16:46 -0800
> > Subject: [ntdev] How to access KeServiceDescriptorTable
> >
> > > Hi,
> > > I have a question with respect to accessing the system service
dispatch
> > > table on win2k drivers.
> > > I am trying to access the SSDT structure exposed by NTOSKRNL as
> > > KeServiceDescriptorTable in my driver routine. But when I try to build
> > > the
> > > driver it is saying that KeServiceDescriptorTable is undeclared
> > > identifier.
> > > Pls let me know which include file I have to include to get rid of
this
> > > compiler error.
> > >
> > > Thanks in advance…
> > >
> > > Sankarshana M
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hollistech.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
Hello Nar,
NGM> Hooking the system services table is a very bad idea. You will probably end
NGM> up with more problems later. If you tell us what you want to debug we can
NGM> suggeste a better method.
NGM> --
NGM> Nar Ganapathy
NGM> Windows Core OS group
Why it is a VERY bad idea? Does Microsoft plan to heavily change the
system services table in next version of Windows?
Which alternative method of hooking native API could you recommend?
What do you think about patching the export table of ntoskrnl.exe to
hook Nt*() functions?
Respectfully yours, Felix.
Felix, really, whether they are or the aren’t or do or they don’t … it
really is no business of yours or your customers UNLESS … you develop code
that is dependent upon the current implementation. Once you start playing
outside the box, things tend to break across platforms and across releases
and across service packs. Unfortunately the perveyor of the OS and not the
wizard of the widget is the one that receives the accolades for breaking
things.
Not to mention the fact that most, if not all software gurus tend to be a
bit arrogant (VERY easily read in your query), and think we can do it
better. Someteims we can’t … but we never ever let on like we can’t. And
you still didn’t answer Nars question. What is it that you NEED, not want,
to do that you think you need to exit the sandbox?
–
Gary G. Little
Have Computer, Will Travel …
909-698-3191
909-551-2105
“Felix K” wrote in message news:xxxxx@ntdev…
>
> Hello Nar,
>
> NGM> Hooking the system services table is a very bad idea. You will
probably end
> NGM> up with more problems later. If you tell us what you want to debug we
can
> NGM> suggeste a better method.
>
> NGM> –
> NGM> Nar Ganapathy
> NGM> Windows Core OS group
>
> Why it is a VERY bad idea? Does Microsoft plan to heavily change the
> system services table in next version of Windows?
>
> Which alternative method of hooking native API could you recommend?
> What do you think about patching the export table of ntoskrnl.exe to
> hook Nt*() functions?
>
> Thanks much.
> —
> Respectfully yours, Felix.
>
>
>
>
Check out this :
http://www.windowsitlibrary.com/Content/356/07/1.html
Regards,
int3
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of sankar
> Sent: Thursday, November 21, 2002 12:17 PM
> To: NT Developers Interest List
> Subject: [ntdev] How to access KeServiceDescriptorTable
>
>
> Hi,
> I have a question with respect to accessing the system
> service dispatch table on win2k drivers. I am trying to
> access the SSDT structure exposed by NTOSKRNL as
> KeServiceDescriptorTable in my driver routine. But when I try
> to build the driver it is saying that
> KeServiceDescriptorTable is undeclared identifier. Pls let me
> know which include file I have to include to get rid of this
> compiler error.
>
> Thanks in advance…
>
> Sankarshana M
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to %%email.unsub%%
>
You are currently subscribed to ntdev as: xxxxx@aalayance.com
To unsubscribe send a blank email to %%email.unsub%%
Hi, All
I have a quick question about the global variable in kernel32.dll.
whenever kernel32!CompareStringW is called, kernel32!gpSysLocHashN is
referenced at the head of it .
What does this global variable manage? I think the head of data structure is
the system Locale.
I don’t think why it need to reference in CompareStringW.
Would you tell me in detail if someone knows about the reason?
Thanks,
Futoshi
System service tables keep changing from release to release. So your code
that works on one release won’t work on another. We can’t make certain
guarantees to our customers if allow random extensions to system service
tables. If you want to add new functionality in a driver you can always use
IOCTL. If you think certain functionality is missing from the DDK we can see
if we can add that in a later release.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Felix K” wrote in message news:xxxxx@ntdev…
>
> Hello Nar,
>
> NGM> Hooking the system services table is a very bad idea. You will
probably end
> NGM> up with more problems later. If you tell us what you want to debug we
can
> NGM> suggeste a better method.
>
> NGM> –
> NGM> Nar Ganapathy
> NGM> Windows Core OS group
>
> Why it is a VERY bad idea? Does Microsoft plan to heavily change the
> system services table in next version of Windows?
>
> Which alternative method of hooking native API could you recommend?
> What do you think about patching the export table of ntoskrnl.exe to
> hook Nt*() functions?
>
> Thanks much.
> —
> Respectfully yours, Felix.
>
>
>
>
Hi,
I wonder if Nar and Microsoft oppose using undocument features, why not
document more and provide OS assist API or extensions to facilitate
developers’ requirements.
Using IOCTL is a far less efficient way of doing things such as extension of
user mode API. Microsoft should add Win32 API so developer could extend API.
Hooking NtXXX API is perfactly safe crossing versions of NT if you know the
API prototype is not changing, regardless of system service table change.
This shall be used in combination of MmGetSystemRoutineAddress to search the
API location in system service table. Nevertheless I would at least check
the OS version first before doing the API hook to guard the possible API
prototype change, which is highly unlikely because OS backward compatiblity
requirement.
Bi
-----Original Message-----
From: Nar Ganapathy[MS] [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, November 26, 2002 10:43 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How to access KeServiceDescriptorTable
System service tables keep changing from release to release. So your code
that works on one release won’t work on another. We can’t make certain
guarantees to our customers if allow random extensions to system service
tables. If you want to add new functionality in a driver you can always use
IOCTL. If you think certain functionality is missing from the DDK we can see
if we can add that in a later release.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Felix K” wrote in message news:xxxxx@ntdev…
>
> Hello Nar,
>
> NGM> Hooking the system services table is a very bad idea. You will
probably end
> NGM> up with more problems later. If you tell us what you want to debug we
can
> NGM> suggeste a better method.
>
> NGM> –
> NGM> Nar Ganapathy
> NGM> Windows Core OS group
>
> Why it is a VERY bad idea? Does Microsoft plan to heavily change the
> system services table in next version of Windows?
>
> Which alternative method of hooking native API could you recommend?
> What do you think about patching the export table of ntoskrnl.exe to
> hook Nt*() functions?
>
> Thanks much.
> —
> Respectfully yours, Felix.
>
>
>
>
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
Nar,
There are many things that eventually lands into this area…
Under 9x there is a fairly (almost ) straight forward way to precisely
capture module load and unload, or to find out what modules are loaded, by
directly hitting MTE, under NT family one has to have an enumeration to find
what is in the system, I might be interested to know when a completely new
(never loaded before in the current system session) module gets loaded, and
very quick, how do I do that ? Also I want to know when it is unloaded and
all of it across process boundaries
Services ard drivers are to extend the OS, so I don’t know why it is not
fully documented, or some api’s are exposed to do that sort of thing…
-prokash
-----Original Message-----
From: Nar Ganapathy[MS] [mailto:xxxxx@windows.microsoft.com]
Sent: Tuesday, November 26, 2002 10:43 AM
To: NT Developers Interest List
Subject: [ntdev] Re: How to access KeServiceDescriptorTable
System service tables keep changing from release to release. So your code
that works on one release won’t work on another. We can’t make certain
guarantees to our customers if allow random extensions to system service
tables. If you want to add new functionality in a driver you can always use
IOCTL. If you think certain functionality is missing from the DDK we can see
if we can add that in a later release.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Felix K” wrote in message news:xxxxx@ntdev…
>
> Hello Nar,
>
> NGM> Hooking the system services table is a very bad idea. You will
probably end
> NGM> up with more problems later. If you tell us what you want to debug we
can
> NGM> suggeste a better method.
>
> NGM> –
> NGM> Nar Ganapathy
> NGM> Windows Core OS group
>
> Why it is a VERY bad idea? Does Microsoft plan to heavily change the
> system services table in next version of Windows?
>
> Which alternative method of hooking native API could you recommend?
> What do you think about patching the export table of ntoskrnl.exe to
> hook Nt*() functions?
>
> Thanks much.
> —
> Respectfully yours, Felix.
>
>
>
>
—
You are currently subscribed to ntdev as: xxxxx@zonelabs.com
To unsubscribe send a blank email to %%email.unsub%%
Hello,
I don’t want to debate on whether hooking system calls
is good/bad.
However, even though, the system service ids can
change across versions/service packs, there is one
guarenteed way of finding out the service id of a
system call irrespective of which version/service pack
you are running on. The way to do this is as follows
All the system calls are exposed to user mode through
NTDLL.DLL as Ntxx functions which contains a wrapper
like
MOV EAX, service id
LEA EDX, [ESP+4]
INT 2E
RET nn
Hence, you can write a user space application, that
walks over the code of these functions to grab the
service id. This service id can then be passed to your
driver and then it can hook that call.
Thanks.
-Prasad
— Bi Chen wrote:
> Hi,
>
> I wonder if Nar and Microsoft oppose using
> undocument features, why not
> document more and provide OS assist API or
> extensions to facilitate
> developers’ requirements.
>
> Using IOCTL is a far less efficient way of doing
> things such as extension of
> user mode API. Microsoft should add Win32 API so
> developer could extend API.
>
> Hooking NtXXX API is perfactly safe crossing
> versions of NT if you know the
> API prototype is not changing, regardless of system
> service table change.
> This shall be used in combination of
> MmGetSystemRoutineAddress to search the
> API location in system service table. Nevertheless I
> would at least check
> the OS version first before doing the API hook to
> guard the possible API
> prototype change, which is highly unlikely because
> OS backward compatiblity
> requirement.
>
> Bi
>
>
> -----Original Message-----
> From: Nar Ganapathy[MS]
> [mailto:xxxxx@windows.microsoft.com]
> Sent: Tuesday, November 26, 2002 10:43 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How to access
> KeServiceDescriptorTable
>
>
> System service tables keep changing from release to
> release. So your code
> that works on one release won’t work on another. We
> can’t make certain
> guarantees to our customers if allow random
> extensions to system service
> tables. If you want to add new functionality in a
> driver you can always use
> IOCTL. If you think certain functionality is missing
> from the DDK we can see
> if we can add that in a later release.
>
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties,
> and confers no rights.
>
> “Felix K” wrote in message
> news:xxxxx@ntdev…
> >
> > Hello Nar,
> >
> > NGM> Hooking the system services table is a very
> bad idea. You will
> probably end
> > NGM> up with more problems later. If you tell us
> what you want to debug we
> can
> > NGM> suggeste a better method.
> >
> > NGM> –
> > NGM> Nar Ganapathy
> > NGM> Windows Core OS group
> >
> > Why it is a VERY bad idea? Does Microsoft plan to
> heavily change the
> > system services table in next version of Windows?
> >
> > Which alternative method of hooking native API
> could you recommend?
> > What do you think about patching the export table
> of ntoskrnl.exe to
> > hook Nt*() functions?
> >
> > Thanks much.
> > —
> > Respectfully yours, Felix.
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> %%email.unsub%%
>
=====
Prasad S. Dabak
Chief Software Architect
Ensim India Private Limited
http://www.ensim.com
Co-author of the book “Undocumented Windows NT”
ISBN 0764545698
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
> I don’t want to debate on whether hooking system calls
is good/bad.
No, just there are tasks which cannot be solved without hooking.
Max
assuming the syscalls in ntdll aren’t changed for the new OS release.
-p
-----Original Message-----
From: Prasad Dabak [mailto:xxxxx@yahoo.com]
Sent: Tuesday, November 26, 2002 10:10 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How to access KeServiceDescriptorTable
Hello,
I don’t want to debate on whether hooking system calls
is good/bad.
However, even though, the system service ids can
change across versions/service packs, there is one
guarenteed way of finding out the service id of a
system call irrespective of which version/service pack
you are running on. The way to do this is as follows
All the system calls are exposed to user mode through
NTDLL.DLL as Ntxx functions which contains a wrapper
like
MOV EAX, service id
LEA EDX, [ESP+4]
INT 2E
RET nn
Hence, you can write a user space application, that
walks over the code of these functions to grab the
service id. This service id can then be passed to your
driver and then it can hook that call.
Thanks.
-Prasad
— Bi Chen wrote:
> Hi,
>
> I wonder if Nar and Microsoft oppose using
> undocument features, why not
> document more and provide OS assist API or
> extensions to facilitate
> developers’ requirements.
>
> Using IOCTL is a far less efficient way of doing
> things such as extension of
> user mode API. Microsoft should add Win32 API so
> developer could extend API.
>
> Hooking NtXXX API is perfactly safe crossing
> versions of NT if you know the
> API prototype is not changing, regardless of system
> service table change.
> This shall be used in combination of MmGetSystemRoutineAddress to
> search the API location in system service table. Nevertheless I
> would at least check
> the OS version first before doing the API hook to
> guard the possible API
> prototype change, which is highly unlikely because
> OS backward compatiblity
> requirement.
>
> Bi
>
>
> -----Original Message-----
> From: Nar Ganapathy[MS]
> [mailto:xxxxx@windows.microsoft.com]
> Sent: Tuesday, November 26, 2002 10:43 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How to access
> KeServiceDescriptorTable
>
>
> System service tables keep changing from release to
> release. So your code
> that works on one release won’t work on another. We
> can’t make certain
> guarantees to our customers if allow random
> extensions to system service
> tables. If you want to add new functionality in a
> driver you can always use
> IOCTL. If you think certain functionality is missing
> from the DDK we can see
> if we can add that in a later release.
>
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties,
> and confers no rights.
>
> “Felix K” wrote in message news:xxxxx@ntdev…
> >
> > Hello Nar,
> >
> > NGM> Hooking the system services table is a very
> bad idea. You will
> probably end
> > NGM> up with more problems later. If you tell us
> what you want to debug we
> can
> > NGM> suggeste a better method.
> >
> > NGM> –
> > NGM> Nar Ganapathy
> > NGM> Windows Core OS group
> >
> > Why it is a VERY bad idea? Does Microsoft plan to
> heavily change the
> > system services table in next version of Windows?
> >
> > Which alternative method of hooking native API
> could you recommend?
> > What do you think about patching the export table
> of ntoskrnl.exe to
> > hook Nt*() functions?
> >
> > Thanks much.
> > —
> > Respectfully yours, Felix.
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> %%email.unsub%%
>
=====
Prasad S. Dabak
Chief Software Architect
Ensim India Private Limited
http://www.ensim.com
Co-author of the book “Undocumented Windows NT”
ISBN 0764545698
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
“Prasad Dabak” wrote in message news:xxxxx@ntdev…
>
> I don’t want to debate on whether hooking system calls
> is good/bad.
>
>
> All the system calls are exposed to user mode through
> NTDLL.DLL as Ntxx functions which contains a wrapper
> like
>
> MOV EAX, service id
> LEA EDX, [ESP+4]
> INT 2E
> RET nn
>
Or not.
In fact, starting with XP, the sequence is slightly different and uses (as
Don Burn mentioned recently) SYSENTER instead of “int 2E”.
See? What you don’t know CAN hurt you…
Peter
OSR
>All the system calls are exposed to user mode through
NTDLL.DLL as Ntxx functions which contains a wrapper
like
MOV EAX, service id
LEA EDX, [ESP+4]
INT 2E
RET nn
Hence, you can write a user space application, that
walks over the code of these functions to grab the
service id. This service id can then be passed to your
driver and then it can hook that call.
Thanks.
-Prasad
That’s too dame complicated if you want parsing Ntdll.dll this way. Also it
does not work for XP since XP will use SYSENTER instead of INT2E.
You could do it in kerenl much much simpler if you have an Zw Version of the
Nt API. The way I mention is one of best way doing it, that does not require
the Nt API has a Zw version.
Bi
— Bi Chen wrote:
> Hi,
>
> I wonder if Nar and Microsoft oppose using
> undocument features, why not
> document more and provide OS assist API or
> extensions to facilitate
> developers’ requirements.
>
> Using IOCTL is a far less efficient way of doing
> things such as extension of
> user mode API. Microsoft should add Win32 API so
> developer could extend API.
>
> Hooking NtXXX API is perfactly safe crossing
> versions of NT if you know the
> API prototype is not changing, regardless of system
> service table change.
> This shall be used in combination of MmGetSystemRoutineAddress to
> search the API location in system service table. Nevertheless I
> would at least check
> the OS version first before doing the API hook to
> guard the possible API
> prototype change, which is highly unlikely because
> OS backward compatiblity
> requirement.
>
> Bi
>
>
> -----Original Message-----
> From: Nar Ganapathy[MS]
> [mailto:xxxxx@windows.microsoft.com]
> Sent: Tuesday, November 26, 2002 10:43 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How to access
> KeServiceDescriptorTable
>
>
> System service tables keep changing from release to
> release. So your code
> that works on one release won’t work on another. We
> can’t make certain
> guarantees to our customers if allow random
> extensions to system service
> tables. If you want to add new functionality in a
> driver you can always use
> IOCTL. If you think certain functionality is missing
> from the DDK we can see
> if we can add that in a later release.
>
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties,
> and confers no rights.
>
> “Felix K” wrote in message news:xxxxx@ntdev…
> >
> > Hello Nar,
> >
> > NGM> Hooking the system services table is a very
> bad idea. You will
> probably end
> > NGM> up with more problems later. If you tell us
> what you want to debug we
> can
> > NGM> suggeste a better method.
> >
> > NGM> –
> > NGM> Nar Ganapathy
> > NGM> Windows Core OS group
> >
> > Why it is a VERY bad idea? Does Microsoft plan to
> heavily change the
> > system services table in next version of Windows?
> >
> > Which alternative method of hooking native API
> could you recommend?
> > What do you think about patching the export table
> of ntoskrnl.exe to
> > hook Nt*() functions?
> >
> > Thanks much.
> > —
> > Respectfully yours, Felix.
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> %%email.unsub%%
>
=====
Prasad S. Dabak
Chief Software Architect
Ensim India Private Limited
http://www.ensim.com
Co-author of the book “Undocumented Windows NT”
ISBN 0764545698
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
Thanks, Beson
I think so, because in normal case *(gpSysLocHasN + 0x1c) have to be able to
be accessible.
I look into this area when calling kernel32!CompareStringW by using SoftICE,
it is always able to be accessible.
Does anyone have any idea?
Thanks,
Futoshi
-----Original Message-----
From: benson [mailto:xxxxx@MAIL.DCHBK.US]
Sent: Thursday, November 28, 2002 5:08 AM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
It does seem as if something is corrupting the locale. I'm afraid I
can't give you any idea as to what.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@citrix.co.jp
Sent: Tuesday, November 26, 2002 11:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
Hi, benson
Actually, I think that this program was written by Microsoft, because
this thread belongs to termsrv.exe. and then MS modules only exist in
call stacks for this thread.
I think this thread are getting Terminal Service License from local or
remote License Server for Terminal Service by activating COM Interface
on License Server. CompareStringW was called during this process with
third parameter "OLE32.dll" second parameter "adsldp.dll" and first
parameter Japanese Locale. I think that adsldp.dll was supported dll to
use Directory Service.
Thanks,
Futoshi
-----Original Message-----
From: benson [mailto:xxxxx@MAIL.DCHBK.US]
Sent: Wednesday, November 27, 2002 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
Where are you getting what you are passing in as the third argument?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@citrix.co.jp
Sent: Tuesday, November 26, 2002 11:02 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
Thanks, benson
But kernel32.dll is a user mode module for ntoskernel.
This dump is also a user dump.
Thanks,
Futoshi
-----Original Message-----
From: benson [mailto:xxxxx@MAIL.DCHBK.US]
Sent: Wednesday, November 27, 2002 2:08 AM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
I'm afraid that you're outside my range. I'm not a kernel person,
really. I know what the third arg is for because it's the same in
user-mode.
Why are you calling CompareStringW instead of, say, memcmp, in the
kernel?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@citrix.co.jp
Sent: Monday, November 25, 2002 8:03 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
Hi, benson
Thanks your information.
I met memory access violation during calling CompareStringW. so I would
like to know about it. I confirmed that Parameters passed to
CompareStringW were correct. However, memory access violation ocuured.
I analyzed userdump. I think this caused that memory area refered to
*(Kernel32!gpSysLocHashN + 0x1c) has already been corrupted for some
reason.
What do you think of it?
Thanks,
Futoshi
Microsoft (R) Windows Debugger Version 6.1.0009.0
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [G:\NEC\30364636\DUMP]
User Dump File: Only application data is available
Windows 2000 Version 2195 UP Free x86 compatible
Product: Server, suite: TerminalServer
System Uptime: not available
Process Uptime: not available
Symbol search path is:
srv*\debug8j\symsrv*Symbol information
;srv*\debug8j\symsrv*Symbol information
Executable search path is:
........................................................................
....
..........
(204.99c): Access violation - code c0000005 (!!! second chance !!!)
eax=0000004f ebx=00000000 ecx=00000061 edx=00230004 esi=e7ffffff
edi=04335548
eip=77e58c02 esp=0335f040 ebp=0335f0a8 iopl=0 nv up ei pl nz na
pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
KERNEL32!CompareStringW+24a:
77e58c02 8b0482 mov eax,[edx+eax*4]
ds:0023:00230140=????????
0:020> r
eax=0000004f ebx=00000000 ecx=00000061 edx=00230004 esi=e7ffffff
edi=04335548
eip=77e58c02 esp=0335f040 ebp=0335f0a8 iopl=0 nv up ei pl nz na
pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
KERNEL32!CompareStringW+24a:
77e58c02 8b0482 mov eax,[edx+eax*4]
ds:0023:00230140=????????
0:020> kv <- the below call stack explain that the server is about to
query TS-CAL for cliet to COM on the MS License Server.
ChildEBP RetAddr Args to Child
0335f0a8 77e5a0c5 77a4d308 00000000 77a4d308
KERNEL32!CompareStringW+0x24a
(FPO: [Non-Fpo])
0335f0cc 77a4da75 77a4d308 04335548 77a4d2f0 KERNEL32!lstrcmpiW+0x1d
(FPO:
[2,0,2])
0335f0e8 77a4d1b4 04335548 77a4d308 00000009 OLE32!wCompareDllName+0x18
(FPO: [Non-Fpo])
0335f31c 77a4d0f0 00000017 00095190 0335f3b8
OLE32!CClassCache::CDllPathEntry::NegotiateDllInstantiationProperties2+0
xce
(FPO: [Non-Fpo])
0335f348 77a4c081 00000017 00000000 00095190
OLE32!CClassCache::CDllPathEntry::NegotiateDllInstantiationProperties+0x
6a
(FPO: [Non-Fpo])
0335f39c 77a7188d 77b031a0 0335f7bc 0335f3b8
OLE32!CClientContextActivator::
CheckInprocClass+0x8a (FPO: [Non-Fpo])
0335f5e8 77a7183a 77b031a0 0335f7bc 0335fd6c
OLE32!CClientContextActivator::
GetClassObject+0x4f (FPO: [Non-Fpo])
0335f5fc 77a4ebc5 0335f7bc 0335fd6c 77a4b238
OLE32!ActivationPropertiesIn::DelegateGetClassObject+0x46 (FPO: [2,0,1])
0335fd78 77a717f9 00000000 00000417 00000000
OLE32!ICoGetClassObject+0x2a5
(FPO: [Non-Fpo])
0335fda4 77a71779 0335fdec 00000417 00000000
OLE32!CComActivator::DoGetClassObject+0x76 (FPO: [Non-Fpo]) 0335fdc4
77a91334 0335fdec 00000417 00000000 OLE32!CoGetClassObject+0x19
(FPO: [Non-Fpo])
0335fe04 77a6ac72 042f2e00 69372ba4 0335fe38 OLE32!FindClassMoniker+0x49
(FPO: [Non-Fpo])
0335fe3c 77364b24 042f2e00 69372ba4 0335fe60
OLE32!MkParseDisplayName+0x9a
(FPO: [Non-Fpo])
0335fe6c 77364a75 69372ba4 69372f38 0335fec0 ACTIVEDS!GetObjectW+0xa7
(FPO:
[Non-Fpo])
0335fe80 69374dd1 69372ba4 69372f38 0335fec0 ACTIVEDS!ADsGetObject+0x13
(FPO: [3,0,0])
0335fecc 69375177 0335fef0 0335ff1c 0335ff20
mstlsapi!GetLicenseSettingsObject+0x7b (FPO: [Non-Fpo]) 0335ff40
6d55454e 00000000 00000000 d5cf8a7b
mstlsapi!GetAllEnterpriseServers+0x59 (FPO: [Non-Fpo]) 0335ffb4 77e587dd
00000318 d5cf8a7b 2cbc84eb ICAAPI!LicenseServerCachingThread+0x2f4 (FPO:
[Non-Fpo]) 0335ffec 00000000 6d55425a 00000318 00000000
KERNEL32!BaseThreadStart+0x52
(FPO: [Non-Fpo])
0:020> u KERNEL32!CompareStringW KERNEL32!CompareStringW+0x24a
KERNEL32!CompareStringW:
77e58af4 55 push ebp
77e58af5 8bec mov ebp,esp
77e58af7 83ec5c sub esp,0x5c
77e58afa 8b0d1804eb77 mov ecx,[KERNEL32!gSystemLocale
(77eb0418)]
77e58b00 53 push ebx
77e58b01 8b5d08 mov ebx,[ebp+0x8]
<- the first parameter, which is locale
77e58b04 56 push esi
77e58b05 8b750c mov esi,[ebp+0xc]
<- the third parameter
77e58b08 57 push edi
77e58b09 81e6ffffffbf and esi,0xbfffffff
77e58b0f 3bd9 cmp
ebx,ecx <-compare the specified
locale with system locale
77e58b11 0f85ba170000 jne KERNEL32!CompareStringW+0x1f
(77e5a2d1)
77e58b17 a190f3ea77 mov eax,[KERNEL32!gpSysLocHashN
(77eaf390)]
77e58b1c 8945dc mov [ebp-0x24],eax
<- [ebp - 0x24] pointed KERNEL32!gpSysLocHashN
77e58b1f 8b7ddc mov edi,[ebp-0x24]
77e58b22 8b4d1c mov ecx,[ebp+0x1c]
77e58b25 33d2 xor edx,edx
77e58b27 6681fb1204 cmp bx,0x412
77e58b2c 0f94c2 sete dl
77e58b2f 83c8ff or eax,0xffffffff
77e58b32 85ff test edi,edi
77e58b34 0f84065a0000 je KERNEL32!CompareStringW+0x89a
(77e5e540)
77e58b3a 837f2400 cmp dword ptr [edi+0x24],0x0
77e58b3e 0f85fc590000 jne KERNEL32!CompareStringW+0x89a
(77e5e540)
77e58b44 394514 cmp [ebp+0x14],eax
77e58b47 0f8ff3590000 jnle KERNEL32!CompareStringW+0x89a
(77e5e540)
77e58b4d 3bc8 cmp ecx,eax
77e58b4f 0f8ff3590000 jnle KERNEL32!CompareStringW+0x8a1
(77e5e548)
77e58b55 83fe01 cmp esi,0x1
77e58b58 0f87e2590000 jnbe KERNEL32!CompareStringW+0x89a
(77e5e540)
77e58b5e 83fa01 cmp edx,0x1
77e58b61 0f84d9590000 je KERNEL32!CompareStringW+0x89a
(77e5e540)
77e58b67 8b5510 mov edx,[ebp+0x10]
77e58b6a 8b7d18 mov edi,[ebp+0x18]
77e58b6d 33db xor ebx,ebx
77e58b6f 895508 mov [ebp+0x8],edx
77e58b72 3bd3 cmp edx,ebx
77e58b74 897d1c mov [ebp+0x1c],edi
77e58b77 0f849e8affff je KERNEL32!CompareStringW+0x88f
(77e5161b)
77e58b7d 3bfb cmp edi,ebx
77e58b7f 0f84968affff je KERNEL32!CompareStringW+0x88f
(77e5161b)
77e58b85 6a02 push 0x2
77e58b87 59 pop ecx
77e58b88 668b02 mov ax,[edx]
77e58b8b 663b07 cmp ax,[edi]
77e58b8e 0f8415140000 je KERNEL32!CompareStringW+0x109
(77e59fa9)
77e58b94 668b02 mov ax,[edx]
77e58b97 663b07 cmp ax,[edi]
77e58b9a 0f8401150000 je KERNEL32!CompareStringW+0x1e1
(77e5a0a1)
77e58ba0 8b4ddc mov ecx,[ebp-0x24]
77e58ba3 895dc8 mov [ebp-0x38],ebx
77e58ba6 f7de neg esi
77e58ba8 1bf6 sbb esi,esi
77e58baa 33c0 xor eax,eax
77e58bac 81e6000000e8 and esi,0xe8000000
77e58bb2 895dd8 mov [ebp-0x28],ebx
77e58bb5 4e dec esi
77e58bb6 395920 cmp [ecx+0x20],ebx
77e58bb9 895db4 mov [ebp-0x4c],ebx
77e58bbc 895dd4 mov [ebp-0x2c],ebx
77e58bbf 0f95c0 setne al
77e58bc2 90 nop
77e58bc3 40 inc eax
77e58bc4 895dcc mov [ebp-0x34],ebx
77e58bc7 0c04 or al,0x4
77e58bc9 895dbc mov [ebp-0x44],ebx
77e58bcc 8945e8 mov [ebp-0x18],eax
77e58bcf 668b02 mov ax,[edx]
77e58bd2 663bc3 cmp ax,bx
77e58bd5 895db8 mov [ebp-0x48],ebx
77e58bd8 895dfc mov [ebp-0x4],ebx
77e58bdb 895d0c mov [ebp+0xc],ebx
77e58bde 8975c4 mov [ebp-0x3c],esi
77e58be1 0f84ef000000 je KERNEL32!CompareStringW+0x7ed
(77e58cd6)
77e58be7 8b7d1c mov edi,[ebp+0x1c]
77e58bea 668b0f mov cx,[edi]
77e58bed 6685c9 test cx,cx
77e58bf0 0f84db000000 je KERNEL32!CompareStringW+0x7e8
(77e58cd1)
77e58bf6 8b55dc mov
edx,[ebp-0x24] <-[ebp - 0x24] pointed
to
the kernel32!gpSysLocHashN
77e58bf9 0fb7c0 movzx eax,ax
77e58bfc 8b521c mov edx,[edx+0x1c]
77e58bff 0fb7c9 movzx ecx,cx
77e58c02 8b0482 mov eax,[edx+eax*4] <- Access violation
occurred at this instruction
0:020> ?edx <- edx has already pointed to invalid area according to the
following Evaluate expression: 2293764 = 00230004 0:020> dd 00230004 l1
00230004 ????????
0:020> ?ebp - 24 <-edx is related with value of [ebp - 0x24]. That is
kernel32!gpSysLocHashN.
<-and then the previous edx value is [edx +
0x1c]. That is *(kernel32!gpSysLocHashN + 0x1c),
<-which is [00230004]
Evaluate expression: 53866628 = 0335f084
0:020> dd 0335f084 l1
0335f084 00074920
0:020> dd gpSysLocHashN l1
77eaf390 00074920
0:020> dd 00074920
00074920 00000411 001bbfe2 001bc072 7ffd8004 // <-0x00000411 is Japanse
Locale 00074930 7ffd8de6 00000000 00000000 00230004
00074940 00000000 00000000 00000000 00000000
00074950 00000000 00000000 00000000 00000000
00074960 00090126 00080100 00000008 00000001
00074970 00074990 00074ab0 00074bd0 00074cf0
00074980 00074e10 00074f30 00075050 00075170
00074990 00000100 77fcfa20 ffffffff 00000000
0:020> dd 0335f0a8
0335f0a8 0335f0e8 77e5a0c5 77a4d308 00000000 // These are parameters of
kernel32!CompareStringW
0335f0b8 77a4d308 ffffffff 04335548 04335548 // This is no
problem.
0335f0c8 77e5a0a8 00000001 77a4da75 77a4d308
0335f0d8 04335548 77a4d2f0 77a4d308 000000c0
0335f0e8 0335f31c 77a4d1b4 04335548 77a4d308
0335f0f8 00000009 80004005 00000000 77b03710
0335f108 00095170 0335f5a4 00000407 00000000
0335f118 00000000 00000000 77a4ad08 00000000
0:020> du 77a4d308
77a4d308 "OLE32.DLL" // this string is null-terminated
0:020> du 04335548
04335548 "adsldp.dll"// this string is null-terminated
0:020> u KERNEL32!lstrcmpiW KERNEL32!lstrcmpiW+0x1d
KERNEL32!lstrcmpiW:
77e5a0a8 53 push ebx
77e5a0a9 8b5c240c mov ebx,[esp+0xc]
77e5a0ad 57 push edi
77e5a0ae 8b7c240c mov edi,[esp+0xc]
77e5a0b2 6aff push 0xff <- null terminated string and
auto
calculate length
77e5a0b4 53 push ebx
77e5a0b5 6aff push 0xff <- null terminated string and
auto
calculate length
77e5a0b7 57 push edi
77e5a0b8 6a01 push 0x1 <- ignore case
77e5a0ba e8d9d7ffff call KERNEL32!GetThreadLocale (77e57898)
77e5a0bf 50 push eax <-0x00000411 is Japanse Locale
77e5a0c0 e82feaffff call KERNEL32!CompareStringW (77e58af4)
-----Original Message-----
From: benson [mailto:xxxxx@MAIL.DCHBK.US]
Sent: Monday, November 25, 2002 10:10 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [kernel32!gpSysLocHashN]
It is looking to see if you want to consider zenkaku and hankaku kana to
be equivalent.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@citrix.co.jp
Sent: Monday, November 25, 2002 6:19 AM
To: NT Developers Interest List
Subject: [ntdev] [kernel32!gpSysLocHashN]
Hi, All
I have a quick question about the global variable in kernel32.dll.
whenever kernel32!CompareStringW is called, kernel32!gpSysLocHashN is
referenced at the head of it . What does this global variable manage? I
think the head of data structure is the system Locale.
I don't think why it need to reference in CompareStringW.
Would you tell me in detail if someone knows about the reason?
Thanks,
Futoshi
You are currently subscribed to ntdev as: xxxxx@dchbk.us
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@citrix.co.jp To
unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@dchbk.us
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@citrix.co.jp To
unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@dchbk.us
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@citrix.co.jp To
unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@dchbk.us
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@citrix.co.jp
To unsubscribe send a blank email to %%email.unsub%%
RE: [ntdev] Re: How to access KeServiceDescriptorTableWhile it is true that
XP uses sysenter instead of int 2E the first instruction is still MOV
eax,serviceID.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Bi Chen
Sent: Wednesday, November 27, 2002 5:17 PM
To: NT Developers Interest List
Subject: [ntdev] Re: How to access KeServiceDescriptorTable
All the system calls are exposed to user mode through
>NTDLL.DLL as Ntxx functions which contains a wrapper
>like
MOV EAX, service id
>LEA EDX, [ESP+4]
>INT 2E
>RET nn
Hence, you can write a user space application, that
>walks over the code of these functions to grab the
>service id. This service id can then be passed to your
>driver and then it can hook that call.
Thanks.
>-Prasad
That’s too dame complicated if you want parsing Ntdll.dll this way. Also
it does not work for XP since XP will use SYSENTER instead of INT2E.
You could do it in kerenl much much simpler if you have an Zw Version of
the Nt API. The way I mention is one of best way doing it, that does not
require the Nt API has a Zw version.
Bi
— Bi Chen wrote:
> Hi,
>
> I wonder if Nar and Microsoft oppose using
> undocument features, why not
> document more and provide OS assist API or
> extensions to facilitate
> developers’ requirements.
>
> Using IOCTL is a far less efficient way of doing
> things such as extension of
> user mode API. Microsoft should add Win32 API so
> developer could extend API.
>
> Hooking NtXXX API is perfactly safe crossing
> versions of NT if you know the
> API prototype is not changing, regardless of system
> service table change.
> This shall be used in combination of MmGetSystemRoutineAddress to
> search the API location in system service table. Nevertheless I
> would at least check
> the OS version first before doing the API hook to
> guard the possible API
> prototype change, which is highly unlikely because
> OS backward compatiblity
> requirement.
>
> Bi
>
>
> -----Original Message-----
> From: Nar Ganapathy[MS]
> [mailto:xxxxx@windows.microsoft.com]
> Sent: Tuesday, November 26, 2002 10:43 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: How to access
> KeServiceDescriptorTable
>
>
> System service tables keep changing from release to
> release. So your code
> that works on one release won’t work on another. We
> can’t make certain
> guarantees to our customers if allow random
> extensions to system service
> tables. If you want to add new functionality in a
> driver you can always use
> IOCTL. If you think certain functionality is missing
> from the DDK we can see
> if we can add that in a later release.
>
>
> –
> Nar Ganapathy
> Windows Core OS group
> This posting is provided “AS IS” with no warranties,
> and confers no rights.
>
> “Felix K” wrote in message news:xxxxx@ntdev…
> >
> > Hello Nar,
> >
> > NGM> Hooking the system services table is a very
> bad idea. You will
> probably end
> > NGM> up with more problems later. If you tell us
> what you want to debug we
> can
> > NGM> suggeste a better method.
> >
> > NGM> –
> > NGM> Nar Ganapathy
> > NGM> Windows Core OS group
> >
> > Why it is a VERY bad idea? Does Microsoft plan to
> heavily change the
> > system services table in next version of Windows?
> >
> > Which alternative method of hooking native API
> could you recommend?
> > What do you think about patching the export table
> of ntoskrnl.exe to
> > hook Nt*() functions?
> >
> > Thanks much.
> > —
> > Respectfully yours, Felix.
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@appstream.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> %%email.unsub%%
>
=====
Prasad S. Dabak
Chief Software Architect
Ensim India Private Limited
http://www.ensim.com
Co-author of the book “Undocumented Windows NT”
ISBN 0764545698
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@bwandel.com
To unsubscribe send a blank email to %%email.unsub%%
Yes I know this. I have used API hooking techniques in
many of production projects. However, I don’t want to
debate on this, since its a never ending topic.
-Prasad
— “Maxim S. Shatskih”
wrote:
> > I don’t want to debate on whether hooking system
> calls
> > is good/bad.
>
> No, just there are tasks which cannot be solved
> without hooking.
>
> Max
>
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
%%email.unsub%%
=====
Prasad S. Dabak
Chief Software Architect
Ensim India Private Limited
http://www.ensim.com
Co-author of the book “Undocumented Windows NT”
ISBN 0764545698
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com