I’ve got a thread handle from which i need to retrieve the thread ID and the process id of the process that owns the thread.
Now i tried calling ZwQueryInformationThread, but the function fails and returns me Access violation. I tried to obtain the CLIENT_ID structure using ObReferenceObjectByHandle, the function succeeds but CLIENT_ID structure is invalid.
Is it that the threadhandle i have does not possess the necessary rights (THREAD_QUERY_INFORMATION). or am i doing wrong somewhere.
Thanks in advance
Regards
Abhishek
If you cann ObRefernceObjectByHandle, you are not going to get a CLIENT_ID, you will get a PETHREAD. How are you getting the handle in the first place? Can you use the process object of the IRP that is sent to you?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, September 22, 2008 11:34 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Obtaining Thread ID from ThreadHandle fails
I’ve got a thread handle from which i need to retrieve the thread ID and the process id of the process that owns the thread.
Now i tried calling ZwQueryInformationThread, but the function fails and returns me Access violation. I tried to obtain the CLIENT_ID structure using ObReferenceObjectByHandle, the function succeeds but CLIENT_ID structure is invalid.
Is it that the threadhandle i have does not possess the necessary rights (THREAD_QUERY_INFORMATION). or am i doing wrong somewhere.
Thanks in advance
Regards
Abhishek
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Yes, I am trying to access the CLIENT_ID field in the ETHREAD structure. and in it the UniqueProcessId value.
I am trying to hook the ZwSuspendThread API and check which process is getting suspended.
It provides me with the threadhandle and i need to determine the owner of this thread.
You can get a process Id from a ETHREAD with IoThreadToProcess with your
thread handle, then use PsGetProcessId to get the PID. Although your ideas
may be noble realize that hacking into ETHREAD structures (which differ
between operating systems) and hooking SuspendThread interfaces are
guaranteed to cause an endless stream of trouble at several levels and thus
defeat their purpose.
//Daniel
wrote in message news:xxxxx@ntdev…
>
> I’ve got a thread handle from which i need to retrieve the thread ID and
> the process id of the process that owns the thread.
>
> Now i tried calling ZwQueryInformationThread, but the function fails and
> returns me Access violation. I tried to obtain the CLIENT_ID structure
> using ObReferenceObjectByHandle, the function succeeds but CLIENT_ID
> structure is invalid.
>
> Is it that the threadhandle i have does not possess the necessary rights
> (THREAD_QUERY_INFORMATION). or am i doing wrong somewhere.
>
> Thanks in advance
> Regards
> Abhishek
>
Thanks Daniel… I got your point
So if you could suggest me how can i attempt to write an application whose threads cannot be suspended, without hooking into the NtSuspendThread . Is threre any legitimate way apart from that.
Just do not do it. Your solution will work only one particular version of
Windows and will not work on all the rest such as 64 bit editions. The
problem with such hooks is that they are incredibly difficult to get right
and very easy to mess up and cause a lot of misery on your customers
machine. Another driver may choose to install such a hook and bypass yours,
you do not want to participate in such a race.
I am not saying you are not asking for something unreasonable but
considering MS policies there are no reasonable means to achieve this.
//Daniel
wrote in message news:xxxxx@ntdev…
> Thanks Daniel… I got your point
> So if you could suggest me how can i attempt to write an application whose
> threads cannot be suspended, without hooking into the NtSuspendThread . Is
> threre any legitimate way apart from that.
>
But there must be a way using which one can perform such operations. I have seen antivirus vendors using hooks in 32 bit systems, but they are still able to perform the same on 64 bit machines. So there’s got to be a way. Are they hacking into the Patchguard or Is the solution a file system mini filter.
If yes then will I be able to perform the same operations such as preventing suspension using a file system filter driver.
Abhishek
Just do not do it. Your solution will work only one particular version of Windows and will not work on > all the rest such as 64 bit editions. The problem with such hooks is that they are incredibly difficult to > get right and very easy to mess up and cause a lot of misery on your customers machine. Another
driver may choose to install such a hook and bypass yours, you do not want to participate in such a
race. I am not saying you are not asking for something unreasonable but considering MS policies
there are no reasonable means to achieve this.
I am not seeing how this could be done by a file system filter. Possibly
they are hooking NtSuspendThread, NtSuspendProcess in user mode using import
address table hooks or something similar. On Win2008 and Vista SP1 there are
object handle creation callbacks (ObRegisterCallbacks) which allows you to
block operations on threads and processes based on desired access but I am
not seeing how this could be successfully used without breaking tons of
existing applications.
//Daniel
wrote in message news:xxxxx@ntdev…
> But there must be a way using which one can perform such operations. I
> have seen antivirus vendors using hooks in 32 bit systems, but they are
> still able to perform the same on 64 bit machines. So there’s got to be a
> way. Are they hacking into the Patchguard or Is the solution a file system
> mini filter.
>
> If yes then will I be able to perform the same operations such as
> preventing suspension using a file system filter driver.
>
> Abhishek
>
>> Just do not do it. Your solution will work only one particular version of
>> Windows and will not work on > all the rest such as 64 bit editions. The
>> problem with such hooks is that they are incredibly difficult to > get
>> right and very easy to mess up and cause a lot of misery on your
>> customers machine. Another
>> driver may choose to install such a hook and bypass yours, you do not
>> want to participate in such a
>> race. I am not saying you are not asking for something unreasonable but
>> considering MS policies
>> there are no reasonable means to achieve this.
>
Use a security descriptor on your process and threads?
Note that if your adversary is an administrator, then you have already lost the entire game before you started it.
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Wednesday, September 24, 2008 02:25
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Obtaining Thread ID from ThreadHandle fails
Thanks Daniel… I got your point
So if you could suggest me how can i attempt to write an application whose threads cannot be suspended, without hooking into the NtSuspendThread . Is threre any legitimate way apart from that.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
There is no documented way to get the thread id from kernel mode. It can
be done trivially from user mode.
Prevent suspension, eh?
Building in this kind of protection simply isn’t worth it. One of my
hats is a software security consultant, and the first thing you should
ask yourself is what exactly is your threat model? Who do you expect to
be attacking your software?
Very few viruses attack anti-virus products. Of the very few that do,
they only attack the big-name AVs, and I have never seen one in the
field that did so intelligently.
If you’re writing an AV product, just make use of the security already
in place (like privileged process isolation). If the virus has gained
root access and is attacking your product, then a security technician is
required to recover the machine anyway. Don’t escalate an expensive arms
race.
As a side note, a large number of systems I’ve had to fix were not due
to viruses, but due to AV products using bad techniques (particularly
when the client decides that if one AV is good, two must be even
better…). In the past, a lot of the big-names fell into this category;
but they are migrating away from this kind of code.
-Stephen Cleary
xxxxx@yahoo.com wrote:
But there must be a way using which one can perform such operations. I have seen antivirus vendors using hooks in 32 bit systems, but they are still able to perform the same on 64 bit machines. So there’s got to be a way. Are they hacking into the Patchguard or Is the solution a file system mini filter.
If yes then will I be able to perform the same operations such as preventing suspension using a file system filter driver.
Abhishek
> Just do not do it. Your solution will work only one particular version of Windows and will not work on > all the rest such as 64 bit editions. The problem with such hooks is that they are incredibly difficult to > get right and very easy to mess up and cause a lot of misery on your customers machine. Another
> driver may choose to install such a hook and bypass yours, you do not want to participate in such a
> race. I am not saying you are not asking for something unreasonable but considering MS policies
> there are no reasonable means to achieve this.
This does not make doing so good practice, or maintainable. Every single AV software which I have seen that did SSDT hooks introduced serious security and stability bugs by doing so.
Not exactly a great thing for a product that is intended to “enhance” security to be in the business of doing.
-----Original Message-----
From: xxxxx@yahoo.com
Sent: Wednesday, September 24, 2008 04:51
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Obtaining Thread ID from ThreadHandle fails
But there must be a way using which one can perform such operations. I have seen antivirus vendors using hooks in 32 bit systems, but they are still able to perform the same on 64 bit machines. So there’s got to be a way. Are they hacking into the Patchguard or Is the solution a file system mini filter.
If yes then will I be able to perform the same operations such as preventing suspension using a file system filter driver.
Abhishek
> Just do not do it. Your solution will work only one particular version of Windows and will not work on > all the rest such as 64 bit editions. The problem with such hooks is that they are incredibly difficult to > get right and very easy to mess up and cause a lot of misery on your customers machine. Another
> driver may choose to install such a hook and bypass yours, you do not want to participate in such a
> race. I am not saying you are not asking for something unreasonable but considering MS policies
> there are no reasonable means to achieve this.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer