Code:
OBJECT_ATTRIBUTES oa = {0};
UNICODE_STRING unObjectPath = {0};
HANDLE hObject;
RtlInitUnicodeString( &unObjectPath, L"\device\harddisk0\dr0" );
InitializeObjectAttributes( &oa, &unObjectPath, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, 0, 0 );
Status = ObOpenObjectByName( &oa, *IoDeviceObjectType, KernelMode, NULL, 0, NULL, &hObject );
return me Status - STATUS_OBJECT_TYPE_MISMATCH in Windows 7 x64
Why?
Maybe it is a sun link? Why not just zwcreatefile instead?
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@yandex.ru
Sent: September 11, 2010 5:25 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ObOpenObjectByName return c0000024
Code:
OBJECT_ATTRIBUTES oa = {0};
UNICODE_STRING unObjectPath = {0};
HANDLE hObject;
RtlInitUnicodeString( &unObjectPath, L"\device\harddisk0\dr0" );
InitializeObjectAttributes( &oa, &unObjectPath, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, 0, 0 );
Status = ObOpenObjectByName( &oa, *IoDeviceObjectType, KernelMode, NULL, 0, NULL, &hObject );
return me Status - STATUS_OBJECT_TYPE_MISMATCH in Windows 7 x64
Why?
—
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
Make that “sym” link (Note to self: Encourage Doron to get a Blackberry).
Examine the object manager’s directory for this object (you can use the ObjDir utility available for free from the downloads section on OSR Online)… Does it indicate this is, in fact, a Device Object?
Peter
OSR
I vaguely recall dealing with the similar issue few years ago. IIRC, I fixed it by specifying
*IoFileObjectType, although I was requesting a pointer to device object. Certainly, don’t take it as an absolute statement because it was quite a while ago so that I cannot recall all the details, but in any case, try it - it is not going to take you that long, is it…
Anton Bassov
I reverse code IopParseDevice and at the beginning of the function is checking IoFileObjectType. However, when I passed *IoFileObjectType function failed elsewhere (in other place) and returned the same status. I conclude that the device should open with ZwOpenFile, and not to use ObOpenObjectByName.
>same status. I conclude that the device should open with ZwOpenFile, and not to use
ObOpenObjectByName.
Absolutely so, this is even documented 
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
To, Maxim S. Shatskih
Yes, but I need a universal function, which returns pointer to object by it full name (ob name). In the case of ZwOpenFile, I can not achieve this versatility (because for the opening of other objects, I using ObOpenObjectByName function).
> Yes, but I need a universal function, which returns pointer to object by it full name (ob name).
There is no such thing in Windows.
For instance, file objects are always nameless from Ob’s point of view, so, no such way for file objects.
Also, let’s imagine you’ve got a device object pointer by name (try ObReferenceObjectByName, for instance). What will you do with it? send IRPs to it? and they will fail since the device object is not prepared to accept them?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
To, Maxim S. Shatskih
I’m not going to open the files (FILE_OBJECT), I’m interested in objects that are in the namespace of the Object Manager. This functionality is necessary for AntiRootkit goals. Quick search for an object in memory, without referencing for it.
>the Object Manager. This functionality is necessary for AntiRootkit goals. Quick search for an object in
memory, without referencing for it.
Well, for such thing it is probably OK to discover the layout of the undocumented “object name” and “object directory” structures, and then follow the pointers.
Probably this will be even safer (if in __try/__except, read-only and on < DISPATCH), then calling undocumented APIs (which can easily have nasty side effects).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
To Maxim S. Shatskih
You are right, but in Win x64 I do not want to use manual directory traversal of the Object Manager, so I rely on the kernel API (ObOpenObjectByName).
And yet, you can not find it strange that the usual API can not open the device object? With that type of open objects coincides with the transmitted type. I believe that is a side effect of parse-procedure (IopParseDevice) of device objects. In this regard, the device objects differ from other objects.
> And yet, you can not find it strange that the usual API can not open the device object?
No, I do not.
People do not need this. You’re the first one to ask for such functionality for years of this forum.
So, the demand is low.
The only goal of the device object is to provide an openable-by-name (and stackable for filtering) endpoint to create file objects.
The only documented way of opening a DO is ZwCreateFile with FILE_READ_ATTRIBUTES, or IoGetDeviceObjectPointer which is a wrapper around it.
parse-procedure (IopParseDevice) of device objects.
Yes. IopParseDevice handicrafts the file object, then the MJ_CREATE IRP and sends the latter to the device object.
And yes, name belongs to the device object, but, if you open this name, you get a file object.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
xxxxx@yandex.ru wrote:
I’m not going to open the files (FILE_OBJECT), I’m interested in objects that are in the namespace of the Object Manager. This functionality is necessary for AntiRootkit goals. Quick search for an object in memory, without referencing for it.
Your task is hopeless. Whatever you can do in your antirootkit program,
the pirates will overcome in the next round. Once an attacker has root
access, the machine is toast. There is no hope.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.