Press "Enter" to skip to content

Why you should not always trust MSDN: Finding Real Access Rights Needed By Handles

Mohammad Sina Karvandi 0


Hi guys,

The title of this topic is somehow weird, if you think everything in MSDN is 100% match with what Microsoft implemented in Windows (like what I used to think), you’re definitely wrong, this post shows some proofs and in the last part, I’ll give you a solution to ACCESS_RIGHTS problem.

Before starting let’s talk about some backgrounds about “ACCESS_MASK“.

Most of the explanations derived from here.


The ACCESS_MASK data type is a DWORD value that defines standard, specific, and generic rights. These rights are used in access control entries (ACEs) and are the primary means of specifying the requested or granted access to an object.

A securable object is an object that can have a security descriptor. All named Windows objects are securable. Some unnamed objects, such as process and thread objects, can have security descriptors too. For most securable objects, you can specify an object’s security descriptor in the function call that creates the object. For example, you can specify a security descriptor in the CreateFile and CreateProcess functions.

Each type of securable object defines its own set of specific access rights and its own mapping of generic access rights. For information about the specific and generic access rights for each type of securable object, see the overview for that type of object.

Here is the list of some objects in Windows (From Windows Internals) that have security descriptor and of course ACCESS_MASK.

The structure of ACCESS_MASK is like this :

For more information you can read these two pdfs.


That’s enough for theory, the reason for creating this post is during the past few days, I was reading “Reading Your Way Around UAC” which is sophisticated research about Windows Access Tokens.

The most interesting part for me was where James Forshaw wrote :

What’s going on? Basically, the documentation is wrong, you don’t need QueryInformation to open the process token only QueryLimitedInformation. You can disassemble NtOpenProcessTokenEx in the kernel if you don’t believe me:

Going back to Vista it’s always been the case that only QueryLimitedInformation was needed, contrary to the documentation. 

For the first time, it was so weird for me, then I ask some of my friends about the things that are implemented in contrary with documentation in MSDN, so yeah, it seems there are things in contrary with MSDN.

That’s enough for me to lose my trust to Microsoft (at least for checking handles’ ACCESS_MASK ) thus I have to somehow check everything by my self but hey, it’s such a boring, isn’t it?

So, I decided to write an IDA Python Plugin for this purpose but let’s see what we really need to look for.

The first thing we need to know is how Windows checks for the desired access. The ObReferenceObjectByHandle function is designed for this purpose and as you can see from the MSDN:

The ObReferenceObjectByHandle routine provides access validation on the object handle, and, if access can be granted, returns the corresponding pointer to the object’s body.

If you search for this function in Ntoskrnl.exe using IDA Pro, you’ll see something like this :

Functions to check for access rights of a handle
Functions to check for access rights of a handle

It seems that there are other functions for this purpose, moreover, if you look at the decompiled source of NtOpenProcessTokenEx you see that ObReferenceObjectByHandle is no longer there instead it replaced by ObpReferenceObjectByHandleWithTag so we should also add this function into our list.

NtOpenProcessToken Decompiled Source
NtOpenProcessToken Decompiled Source

From the ObpReferenceObjectByHandleWithTag you can see that the contarary still remains in MSDN. If you look at the second argument to ObpReferenceObjectByHandleWithTag you can see 0x1000 and it’s, of course, PROCESS_QUERY_LIMITED_INFORMATION while the MSDN have mentioned something else.


The documentation for OpenProcessToken:


Functions to Test

Actually, we just need to test the following function (from the functions available in IDA search results):





Other functions are not really important to us, as I saw their XREFs, for example :


As you can see the above function doesn’t seems to valuable in our case from the XREFs results.

IDA Python Script

The following code is the IDA Python script for finding XREFs of our target function then find the second argument from the decompiled source:


Here is the results, you can use them if you don’t have IDA Pro:


A complete list of result :

Note: If you want to use the results, you can find functions which start with (NT*) that’s because these functions have a pair in user-mode ntdll, so if your user-mode function ends to a ntdll native function then you can search for the same function and see the reall access rights.


In this post, you saw how it might be different, the real implementation over documentation so as a conclusion if you are a security researcher, it’s always better to check the real source code (decompiled) instead of just trusting the documentation.

That’s it guys, hope you enjoy it.

Aniiiiiiiiiime :)


[1] Reading Your Way Around UAC (Part 2) – (

[2] ObReferenceObjectByHandle function – (

[3] Process Security and Access Rights – (

[4] Enumerate all XefsTo a Segment in IDAPython – (

[5] OpenProcessToken function – (

[6] About the ACCESS_MASK Structure – (


[8] ObpReferenceProcessObjectByHandle – (

Leave a Reply

Your email address will not be published. Required fields are marked *