{"id":35,"date":"2006-10-02T00:55:48","date_gmt":"2006-10-02T00:55:48","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2006\/10\/02\/rtlgetmodulebase-rtlgetprocaddress\/"},"modified":"2026-07-27T20:44:47","modified_gmt":"2026-07-27T20:44:47","slug":"rtlgetmodulebase-rtlgetprocaddress","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2006\/10\/02\/rtlgetmodulebase-rtlgetprocaddress\/","title":{"rendered":"RtlGetModuleBase & RtlGetProcAddress"},"content":{"rendered":"
\"\"<\/a><\/div>\n

In the post ExAllocatePool (WithoutTag)<\/a>, I talked a little about the conflicts on using new APIs in drivers and making them incompatible with legacy systems. Our initial proposal was to have a single binary that would be able to run either in Windows NT and newer systems. We reached a solution that cannot be considered ideal, that old functions are always used on systems that support newer APIs.<\/p>\n

Thinking about solving this limitation, the DDK brought us MmGetSystemRoutineAddress()<\/a>. Analogous to GetProcAddress()<\/a> exported by kernel32.dll, MmGetSystemRoutineAddress()<\/em> dynamically obtains a function address from its exported name. But the world will not still be safe while Windows NT survives. This new function has only been implemented since Windows 2000.<\/p>\n

We don’t have an alternative to Windows NT, so let’s make one. With one or two PE concepts, we implemented this function version. PE structure carries tons of rules, but for our need we can implement a light version. If you want details about the rules adopted by PE, you can take a look at the article An In-Depth Look into the Win32 Portable Executable File Format<\/a> by Matt Pietrek.<\/p>\n

Well, now that we already have read the entire article and already known everything about PE, follow the basic algorithm prototype about how to walk through PE structure, looking for a specific function exported by name. This function is not provided by Windows NT DDK and is written in the example source code available for downloading.<\/p>\n

\n
NTSTATUS RtlGetProcAddress(IN PVOID     pBaseAddress,<\/pre>\n
                           IN LPCSTR    pszFunctionName,<\/pre>\n
                           IN NTPROC    *pProcedure);<\/pre>\n<\/div>\n
Notice that the input parameters are the base address, the name of desired function and ultimately the address to the pointer that will get the obtained function address. But where will I get this base address from? Remember the functions we are looking for are exported by ntoskrnl.lib<\/strong> and they are implemented in the ntoskrnl.exe<\/strong> module. To make sure the function we’re looking for is in fact exported by this module, use the “Dependency Walker”<\/em> to see this module export table. As I said before, some functions are implemented as macros, thus, its definition will be in a header file and not in the export table.<\/p>\n
\"\"<\/div>\n
To get the module base address that exports these functions, we use ZwQuerySystemInformation()<\/a> in which, although not documented by Microsoft, there are already several publications that comment about it. Thus, we’ll define the RtlGetModuleBase()<\/strong> which will behave similar to the well-known GetModuleHandle()<\/a>. This function is also defined in the example available for downloading.<\/p>\n
\n
NTSTATUS<\/pre>\n
NTAPI<\/pre>\n
ZwQuerySystemInformation(IN SYSTEM_INFORMATION_CLASS SystemInformationClass,<\/pre>\n
                         IN OUT PVOID SystemInformation,<\/pre>\n
                         IN ULONG SystemInformationLength,<\/pre>\n
                         OUT PULONG ReturnLength OPTIONAL)<\/pre>\n<\/div>\n
There are many undocumented features and settings that can be extremely useful. The book Windows NT\/2000 Native API Reference<\/a> by Gary Nebbett is excellent to make use of these functions. He brings prototypes, enums, structures used in calls, descriptions of what each function does and each parameter. Here in our example, we only use the statements below for information about the modules loaded into the system address space.<\/p>\n
\n
typedef<\/span> struct<\/span> _SYSTEM_MODULE_INFORMATION   \/\/ Information Class 11<\/span><\/pre>\n
{<\/pre>\n
    ULONG Reserved[2<\/span>];<\/pre>\n
    PVOID Base;<\/pre>\n
    ULONG Size;<\/pre>\n
    ULONG Flags;<\/pre>\n
    USHORT Index;<\/pre>\n
    USHORT Unknown;<\/pre>\n
    USHORT LoadCount;<\/pre>\n
    USHORT ModuleNameOffset;<\/pre>\n
    CHAR ImageName[256<\/span>];<\/pre>\n
 <\/pre>\n
} SYSTEM_MODULE_INFORMATION, *PSYSTEM_MODULE_INFORMATION;<\/pre>\n<\/div>\n
The structure “Base” member above brings us the module base address containing PE structure. In the sample code,  is RtlGetModuleBase()<\/strong> routine definition that has the following prototype.<\/p>\n
\n
NTSTATUS RtlGetModuleBase(IN LPCSTR     pszModuleName,<\/pre>\n
                          OUT PVOID*    ppBaseAddress);<\/pre>\n<\/div>\n
With the union of its powers, now we can know whether a certain API is implemented in the current system and if so, get its address. So, it is perfectly possible to have a single binary that can run on both Windows NT using ExFreePool()<\/a> and in later systems using ExFreePoolWithTag()<\/a>. Below it is a very basic example as always. Of course, we can create a single allocation routine that would do the dirty work.<\/p>\n
\n
#include<\/span> \"GetProcAddr.h\"<\/span><\/pre>\n
 <\/pre>\n
\/\/-f--> Type for the ExFreePoolWithTag routine<\/span><\/pre>\n
typedef<\/span> VOID (NTAPI* PF_EX_FREE_POOL_WITH_TAG)<\/pre>\n
(<\/pre>\n
    IN PVOID  P,<\/pre>\n
    IN ULONG  Tag <\/pre>\n
);<\/pre>\n
 <\/pre>\n
 <\/pre>\n
VOID OnDriverUnload(PDRIVER_OBJECT     pDriverObj)<\/pre>\n
{<\/pre>\n
    \/\/-f--> That routine, even empty, is here just<\/span><\/pre>\n
    \/\/      to allow the driver to be unloaded.<\/span><\/pre>\n
}<\/pre>\n
 <\/pre>\n
 <\/pre>\n
\/****<\/span><\/pre>\n
***<\/span><\/pre>\n
**           There once was a Driver...<\/span><\/pre>\n
**<\/span><\/pre>\n
*\/<\/span><\/pre>\n
NTSTATUS DriverEntry(PDRIVER_OBJECT     pDriverObj,<\/pre>\n
                     PUNICODE_STRING    pusRegistryPath)<\/pre>\n
{<\/pre>\n
    NTSTATUS                    nts;<\/pre>\n
    PVOID                       pBaseAddress, pTemp;<\/pre>\n
    PF_EX_FREE_POOL_WITH_TAG    pfExFreePoolWithTag;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Set the unload callback routine<\/span><\/pre>\n
    pDriverObj->DriverUnload = OnDriverUnload;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Get the module base address<\/span><\/pre>\n
    nts = RtlGetModuleBase(\"ntoskrnl.exe\"<\/span>,<\/pre>\n
                           &pBaseAddress);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Testing the routine's return doesn't hurt,<\/span><\/pre>\n
    \/\/      but not doing this can kill your system.<\/span><\/pre>\n
    if<\/span> (!NT_SUCCESS(nts))<\/pre>\n
        return<\/span> nts;<\/pre>\n
 <\/pre>\n
    \/\/-f--> Allocating memory for a test using the Free routine<\/span><\/pre>\n
    pTemp = ExAllocatePoolWithTag(NonPagedPool,<\/pre>\n
                                  10<\/span>,<\/pre>\n
                                  'tseT'<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Get the function API address<\/span><\/pre>\n
    nts = RtlGetProcAddress(pBaseAddress,<\/pre>\n
                            \"ExFreePoolWithTag\"<\/span>,<\/pre>\n
                            (NTPROC*)&pfExFreePoolWithTag);<\/pre>\n
 <\/pre>\n
    if<\/span> (NT_SUCCESS(nts))<\/pre>\n
    {<\/pre>\n
        \/\/-f--> If that routine is implemented by the system, so<\/span><\/pre>\n
        \/\/      we get a success return code here.<\/span><\/pre>\n
        pfExFreePoolWithTag(pTemp,<\/pre>\n
                            'tseT'<\/span>);<\/pre>\n
    }<\/pre>\n
    else<\/span><\/pre>\n
    {<\/pre>\n
        \/\/-f--> Who has no dog, hunts like a cat.<\/span><\/pre>\n
        ExFreePool(pTemp);<\/pre>\n
    }<\/pre>\n
 <\/pre>\n
    return<\/span> STATUS_SUCCESS;<\/pre>\n
}<\/pre>\n<\/div>\n
Have fun! \ud83d\ude42<\/p>\n
ExGetProc.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In the post ExAllocatePool (WithoutTag), I talked a little about the conflicts on using new APIs in drivers and making them incompatible with legacy systems. Our initial proposal was to have a single binary that would be able to run either in Windows NT and newer systems. We reached a solution that cannot be considered […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-35","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/35","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=35"}],"version-history":[{"count":4,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/35\/revisions"}],"predecessor-version":[{"id":313,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/35\/revisions\/313"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=35"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=35"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=35"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}