Accessing Windows Native API from User-Mode

Question

I'm quite curious about the Windows Native API. I have been searching around the net and have failed to find an example of calling a Native API function from user-mode. I believe I have a basic grasp of what this entails - specifically, I have to define constants and the native API function in my program, and use GetProcAddress to find the function in ntdll.dll, and then call the function.

Is this correct, and can anyone steer me in the right direction? Sample code would make my day, as I can find absolutely none of it.

I came across this code here ( http://www.eggheadcafe.com/software/aspnet/31520494/native-application--ntc.aspx ), but it seems to me that it is intended to operate in kernel mode:

NTSTATUS    ntStatus = STATUS_SUCCESS;
UNICODE_STRING   szPath  = {0};
OBJECT_ATTRIBUTES   Attr  = {0};
IO_STATUS_BLOCK   IoStatusBlock = {0};
HANDLE     hBeep  = 0;

RtlInitUnicodeString(&szPath, L"\\??\\C:\\A.TXT");
InitializeObjectAttributes(&Attr, &szPath, 0, NULL, NULL);

ntStatus = NtCreateFile(&hBeep, GENERIC_READ, &Attr, &IoStatusBlock, NULL,
0, FILE_SHARE_READ, FILE_OPEN, 0, NULL, 0);

if (hBeep != NULL)
{
NtClose(ntStatus);

How could this code be modified to operate in user-mode? I'm working in c++, as you probably have surmised by this point.

Thanks in advance.

Answer 1

I'm not a big fan of using undocumented APIs, but occasionally you need to do something that isn't exposed by the Win32 API. Some of the native API has been documented on MSDN (probably due to the settlement a while back). I usually use the reference at NTinternals.net, though it hasn't been updated in a while and it uses a terrible Java applet for navigation. There are probably some code examples on places like The Code Project et al.

Answer 2

NtCreateFile() is already a user-mode function. The driver version is ZwCreateFile(). It is in fact documented, the declaration is available in the winternl.h SDK header file. What's missing however is the import library for ntdll.dll, you have to use LoadLibrary and GetProcAddress to get the entrypoint for the function.

Other than the trouble of calling it, the usual caveat is that these native API functions can change without notice in the next version of Windows.