I’ve been researching the ObOpenObjectByName function, which seems to be an undocumented internal API in the Windows NT kernel. This function is included in ntoskrnl.exe, but I am unclear if it can be used in user mode applications.
From my understanding, this is a low-level NT API that works at the kernel level. I’m curious if there’s a way to call this function from a typical Windows application running in user space. If it is feasible, what would be the right approach to link my application with ntoskrnl?
I have looked for documentation, but there is a lack of information regarding this specific API. Has anyone been able to use this function from within user mode? Any tips on the linking process or other solutions would be greatly appreciated.
ObOpenObjectByName only works in kernel space - you can’t call it from user mode apps. Your best bet is using Native API functions from ntdll.dll instead. Try NtOpenSymbolicLinkObject, NtQueryDirectoryObject, or NtOpenSection - they’ll let you access the NT object manager namespace from user mode. These APIs aren’t documented, but you can load them with GetProcAddress. Just heads up - undocumented APIs can break between Windows versions. Before going down this rabbit hole, double-check if the regular Win32 APIs can handle what you’re trying to do.
Calling ObOpenObjectByName from user mode is not possible, as this function is kernel-only and resides in ntoskrnl.exe. It operates at ring 0, requiring kernel context to access object manager structures. Attempting to link to ntoskrnl.exe in user space will result in runtime failures, as kernel exports cannot be resolved in that context. If you need to interact with NT objects, consider using the documented APIs like NtOpenFile or NtOpenKey, which allow safe access from user mode. For kernel-level operations, developing a kernel driver is necessary to utilize ObOpenObjectByName and facilitate communication with your user application through DeviceIoControl.
nah, you can’t call it directly from usermode - it’s kernel only. but check out ntdll.dll functions like NtOpenDirectoryObject or other native apis. they’ll get you close to what you need without having to mess with kernel driver stuff.