ObReferenceObjectByHandle issue

OSR_Community_User · December 8, 2009, 2:34pm

Hi,

My question refers to Windows XP. I am working on an application + driver package, where the driver informs the application using events.

The following code is used:
Application side:
m_ testHandle = ::CreateEvent(NULL, FALSE, FALSE, NULL);

the driver receives the handle using DeviceIoContol, checks the handle validity and use the handle returned by ObReferenceObjectByHandle.

if(ObReferenceObjectByHandle(testHandle,
EVENT_MODIFY_STATE,
*ExEventObjectType,
UserMode,
(PVOID*)&TestEvent,
NULL) == STATUS_SUCCESS)
{
//everything is OK
}
Else
{
//set handle to NULL
}

The application worked perfectly until the following changes took place:

The application now uses a named pipe to connect to a service, the service sends the DeviceIoContol message to the driver.

Nothing else changed, the application still defines the handle using CreateFile, and the driver runs the same ObReferenceObjectByHandle function as before.
For some reason the driver determines that the handle is invalid and will not return STATUS_SUCCESS.

Thanks.
Guy

Michal_Vodicka-2 · December 8, 2009, 2:41pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@airspan.com
Sent: Tuesday, December 08, 2009 8:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObReferenceObjectByHandle issue

The application worked perfectly until the following changes
took place:

The application now uses a named pipe to connect to a
service, the service sends the DeviceIoContol message to the driver.

Nothing else changed, the application still defines the
handle using CreateFile, and the driver runs the same
ObReferenceObjectByHandle function as before.
For some reason the driver determines that the handle is
invalid and will not return STATUS_SUCCESS.

Who creates the event? Application or the service? How can application
call CreateFile and the service call DeviceIoControl?

What is the status code returned by ObReferenceObjectByHandle?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Tim_Roberts · December 8, 2009, 2:47pm

xxxxx@airspan.com wrote:

My question refers to Windows XP. I am working on an application + driver package, where the driver informs the application using events.

The following code is used:
Application side:
m_ testHandle = ::CreateEvent(NULL, FALSE, FALSE, NULL);
…
The application worked perfectly until the following changes took place:

The application now uses a named pipe to connect to a service, the service sends the DeviceIoContol message to the driver.

Nothing else changed, the application still defines the handle using CreateFile, and the driver runs the same ObReferenceObjectByHandle function as before.
For some reason the driver determines that the handle is invalid and will not return STATUS_SUCCESS.

You have the application send the handle to the service, which then
calls the ioctl? Of course that fails. Handles are only valid within
the process that created them. When the application sends the handle
down, the driver is trying to find the handle within the service
process. Naturally, it’s not there.

You could use a named handle, then pass the name to the service and have
it use OpenEvent to get another handle to the same event.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Doron_Holan · December 8, 2009, 2:57pm

Is the service sending a handle value created by the app or a handle value created by the service?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@airspan.com
Sent: Tuesday, December 08, 2009 11:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObReferenceObjectByHandle issue

Hi,

My question refers to Windows XP. I am working on an application + driver package, where the driver informs the application using events.

The following code is used:
Application side:
m_ testHandle = ::CreateEvent(NULL, FALSE, FALSE, NULL);

the driver receives the handle using DeviceIoContol, checks the handle validity and use the handle returned by ObReferenceObjectByHandle.

if(ObReferenceObjectByHandle(testHandle,
EVENT_MODIFY_STATE,
*ExEventObjectType,
UserMode,
(PVOID*)&TestEvent,
NULL) == STATUS_SUCCESS) {
//everything is OK
}
Else
{
//set handle to NULL
}

The application worked perfectly until the following changes took place:

The application now uses a named pipe to connect to a service, the service sends the DeviceIoContol message to the driver.

Nothing else changed, the application still defines the handle using CreateFile, and the driver runs the same ObReferenceObjectByHandle function as before.
For some reason the driver determines that the handle is invalid and will not return STATUS_SUCCESS.

Thanks.
Guy

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

Gary_Little-3 · December 8, 2009, 3:06pm

The general consensus here is to NOT use pipes between user and kernel
modes. There are timing issues that simply cannot be overcome when using
pipes. The recommended solution is defining the IOCTL codes you need and
using DeviceIoControl in an invereted callback if needed.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@airspan.com
Sent: Tuesday, December 08, 2009 1:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObReferenceObjectByHandle issue

Hi,

My question refers to Windows XP. I am working on an application + driver
package, where the driver informs the application using events.

The following code is used:
Application side:
m_ testHandle = ::CreateEvent(NULL, FALSE, FALSE, NULL);

the driver receives the handle using DeviceIoContol, checks the handle
validity and use the handle returned by ObReferenceObjectByHandle.

if(ObReferenceObjectByHandle(testHandle,
EVENT_MODIFY_STATE,
*ExEventObjectType,
UserMode,
(PVOID*)&TestEvent,
NULL) == STATUS_SUCCESS)
{
//everything is OK
}
Else
{
//set handle to NULL
}

The application worked perfectly until the following changes took place:

The application now uses a named pipe to connect to a service, the
service sends the DeviceIoContol message to the driver.

Nothing else changed, the application still defines the handle using
CreateFile, and the driver runs the same ObReferenceObjectByHandle function
as before.
For some reason the driver determines that the handle is invalid and will
not return STATUS_SUCCESS.

Thanks.
Guy

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

__________ Information from ESET Smart Security, version of virus signature
database 4671 (20091208) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 4671 (20091208) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Michal_Vodicka-2 · December 8, 2009, 3:10pm

But he wrote he uses named pipe between the app and the service. Anyway,
the post is confusing and should be clarified as several of us already
asked.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, December 08, 2009 9:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ObReferenceObjectByHandle issue

The general consensus here is to NOT use pipes between user and kernel
modes. There are timing issues that simply cannot be overcome
when using
pipes. The recommended solution is defining the IOCTL codes
you need and
using DeviceIoControl in an invereted callback if needed.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@airspan.com
Sent: Tuesday, December 08, 2009 1:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObReferenceObjectByHandle issue

Hi,

My question refers to Windows XP. I am working on an
application + driver
package, where the driver informs the application using events.

The following code is used:
Application side:
m_ testHandle = ::CreateEvent(NULL, FALSE, FALSE, NULL);

the driver receives the handle using DeviceIoContol, checks the handle
validity and use the handle returned by ObReferenceObjectByHandle.

if(ObReferenceObjectByHandle(testHandle,
EVENT_MODIFY_STATE,
*ExEventObjectType,
UserMode,
(PVOID*)&TestEvent,
NULL) == STATUS_SUCCESS)
{
//everything is OK
}
Else
{
//set handle to NULL
}

The application worked perfectly until the following changes
took place:

The application now uses a named pipe to connect to a
service, the
service sends the DeviceIoContol message to the driver.

Nothing else changed, the application still defines the handle using
CreateFile, and the driver runs the same
ObReferenceObjectByHandle function
as before.
For some reason the driver determines that the handle is
invalid and will
not return STATUS_SUCCESS.

Thanks.
Guy

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

__________ Information from ESET Smart Security, version of
virus signature
database 4671 (20091208) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of
virus signature
database 4671 (20091208) __________

The message was checked by ESET Smart Security.

http://www.eset.com

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

Maxim_S_Shatskih · December 8, 2009, 7:09pm

> The application worked perfectly until the following changes took place:

The application now uses a named pipe to connect to a service, the service sends the
DeviceIoContol message to the driver.

The service should DuplicateHandle the handle.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · December 9, 2009, 2:33am

Hi,
First of all sorry for the confusing partial description (not familiar enough with this material), and thanks for your help.
A few clarifications:

Connections between application and service id done using named pipe.
The service calls the CreateFile and DeviceIoControl (this is the only action done by the application regarding to this event,except listening).
The application calls CreateEvent, the handle is forwarded to the service. The service use deviceIoControl to forward it to the Driver.
ObReferenceObjectByHandle returned status ? Currently only checked against STATUS_SUCCESS, I will update the driver code and extract it ASAP.
KeSetEvent is called only by driver.
Handle value is set by the application and not altered by the service.

Regarding to Named handle and dupicate handle I will check the FAQ, thpugh any recomendatios of sources, smaple codes etc are more than welcome.

If I understand it correctly, using the handle from CreateEvent (unless switching to named one or duplicating it) is only possible by the entity which called the CreateFile and DeviceIoControl?

Thanks a lot.
Guy

Doron_Holan · December 9, 2009, 3:12am

> If I understand it correctly, using the handle from CreateEvent (unless switching to named one or duplicating it) is only possible by the entity which called the CreateFile and DeviceIoControl?

Typically yes. In this case if you duplicate the handle into the service’s processs (via DuplicateHandle() after you impersonate the client app) and pass the duplicated handle value to the driver via the IOCTL, your design should work. You can even close the duplicated handle after the “set” IOCTL succeeds.

Connections between application and service id done using named pipe.
Any reason you are not using RPC? Much simpler and a much better paradigm for passing data, esp data that needs to be marshaled. RPC also makes the impersonation pretty simple

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@airspan.com
Sent: Tuesday, December 08, 2009 11:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ObReferenceObjectByHandle issue

Hi,
First of all sorry for the confusing partial description (not familiar enough with this material), and thanks for your help.
A few clarifications:

Connections between application and service id done using named pipe.
The service calls the CreateFile and DeviceIoControl (this is the only action done by the application regarding to this event,except listening).
The application calls CreateEvent, the handle is forwarded to the service. The service use deviceIoControl to forward it to the Driver.
ObReferenceObjectByHandle returned status ? Currently only checked against STATUS_SUCCESS, I will update the driver code and extract it ASAP.
KeSetEvent is called only by driver.
Handle value is set by the application and not altered by the service.

Regarding to Named handle and dupicate handle I will check the FAQ, thpugh any recomendatios of sources, smaple codes etc are more than welcome.

If I understand it correctly, using the handle from CreateEvent (unless switching to named one or duplicating it) is only possible by the entity which called the CreateFile and DeviceIoControl?

Thanks a lot.
Guy

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

OSR_Community_User · December 9, 2009, 4:22am

Hi,
Thanks, I will duplicate the handle in the service process.
Let me see if I got it right:

Create a “real” process handle of my application by calling GetCurrentProcess and DuplicateHandle of the created pseudo process handle.
I pass the event handle parameter and the “real” process handle to the service.
From Service I call the DuplicateHandle functionality.
the duplicated handle is sent to the deriver.

Is this th right flow?

Thanks.
Guy

Maxim_S_Shatskih · December 9, 2009, 8:40am

> 3. The application calls CreateEvent, the handle is forwarded to the service. The service use

deviceIoControl to forward it to the Driver.

The service must use DuplicateHandle+DeviceIoControl to forward it to the driver.

The reason is that ObReferenceObjectByHandle in the IOCTL path of the driver works in the known process context - the service’s context in this case. And, the handles are per-process - they are the indices to the per-process handle table.

So, the service must convert the app’s handle to the service’s handle - i.e. call DuplicateHandle. This allocates the entry in the service’s handle table which is a synonim of the entry of the app’s handle table.

More so: this is true for any Win32 user mode work. If you transfer the handles from one process to another just by value - then you need to call DuplicateHandle in the receiving process and only use the duplicate after it.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · December 9, 2009, 8:41am

> 4. the duplicated handle is sent to the deriver.

Why are you sending the process handle to the driver?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · December 9, 2009, 8:44am

> your design should work. You can even close the duplicated handle after the “set” IOCTL succeeds.

I would do DuplicateHandle in the “unmarshal” code which parses the data packet came from app, not in the “implementation” code which calls DeviceIoControl.

The reason is that un-duplicated other-side handle has no meaning in the service except as a duplicate source, it cannot be used as a handle in any Win32 API (except duplication), and thus should be hidden from the implementation.

A matter of taste though.

And yes, RPC (easily implemented over named pipes) is a solution. DCOM is even better solution - there is an ATL framework to write DCOM servers and <comdef.h> header to help coding the client.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com</comdef.h>

OSR_Community_User · December 10, 2009, 2:42am

Hi,
Process handle will not be forwarded to the driver, only to the service (for duplicate handle purposes).
Can anyone recommend a good reading material regarding which covers this area?
Thank you all
Guy

Doron_Holan · December 10, 2009, 2:48am

Again, rpc takes care of a lot of this for you and gives you a much cleaner calling interface

d

-----Original Message-----
From: xxxxx@airspan.com
Sent: Wednesday, December 09, 2009 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ObReferenceObjectByHandle issue

Hi,
Process handle will not be forwarded to the driver, only to the service (for duplicate handle purposes).
Can anyone recommend a good reading material regarding which covers this area?
Thank you all
Guy

—
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

Maxim_S_Shatskih · December 11, 2009, 8:50pm

> Can anyone recommend a good reading material regarding which covers this area?

Any good Win32 book, or MSDN Library chapter on Win32 handles.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com