Kernel-mode LoadLibrary, GetProcAddress

Good day to All.

Internet searches reveal that the fine folks in this forum have attempted to answer the question before, as well as to probe as to the questioner’s purpose/intentions. I don’t know why the questioners didn’t respond.

I am interested in kernel-mode LoadLibrary() and GetProcAddress() counterparts because I’d like to compile my driver into just two build types: x86 and x64 (maybe IA-64 as a third).

I’d like to aim for linking against, let’s say, Windows 2000, but to activate certain additional features if I detect a newer OS. This way, the same binary “works” for all OS versions with the same architecture; it’d just have a more limited feature-set where dependencies could not be satisfied.

A specific example (but only an example) would be the absence of PsDereferencePrimaryToken() from Windows 2000. I could have #if-#endif spaghetti and lots of different builds, or I could have a wrapper check for availability at run-time and memoize the result, with a single build.

Similarly, I could audit my driver’s code for functions which deprecate with newer OS versions and wrap them appropriately… It’d be nice to be able to determine, “it’s so deprecated that it’s not even exported with this kernel version,” for instance.

Is this a silly approach? Has anyone some nice open source code that could help, or some code samples as tips? I’d read about hand-coding PE image routines, but wouldn’t like to re-invent any wheels.

Thank you for your attention.

RtlGetVersion/RtlIsNtDdiVersionAvailable and MmGetSystemRoutineAddress may be what you’re looking for. Be aware that there was a bug in MmGetSystemRoutineAddress if called for an export that does not exist on older OS releases; see http://www.osronline.com/article.cfm?article=494 for more details.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@YRDSB.Edu.On.Ca
Sent: Thursday, January 20, 2011 6:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Kernel-mode LoadLibrary, GetProcAddress

Good day to All.

Internet searches reveal that the fine folks in this forum have attempted to answer the question before, as well as to probe as to the questioner’s purpose/intentions. I don’t know why the questioners didn’t respond.

I am interested in kernel-mode LoadLibrary() and GetProcAddress() counterparts because I’d like to compile my driver into just two build types: x86 and x64 (maybe IA-64 as a third).

I’d like to aim for linking against, let’s say, Windows 2000, but to activate certain additional features if I detect a newer OS. This way, the same binary “works” for all OS versions with the same architecture; it’d just have a more limited feature-set where dependencies could not be satisfied.

A specific example (but only an example) would be the absence of PsDereferencePrimaryToken() from Windows 2000. I could have #if-#endif spaghetti and lots of different builds, or I could have a wrapper check for availability at run-time and memoize the result, with a single build.

Similarly, I could audit my driver’s code for functions which deprecate with newer OS versions and wrap them appropriately… It’d be nice to be able to determine, “it’s so deprecated that it’s not even exported with this kernel version,” for instance.

Is this a silly approach? Has anyone some nice open source code that could help, or some code samples as tips? I’d read about hand-coding PE image routines, but wouldn’t like to re-invent any wheels.

Thank you for your attention.


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

Thank you for the great response.

It would appear that it’s not a silly idea at all, based on the fact that there is a Microsoft article, “Writing a Multiversion Driver That Uses Version-Dependent Features.” I found that link while following your function pointers. (Pun.)

Will check the bug you mentioned.

> A specific example (but only an example) would be the absence of PsDereferencePrimaryToken()

from Windows 2000.

MmGetSystemRoutineAddress helps.

Note that with some function names on some pre-service-pack OSes (XP pre-SP2?) it can crash the OS due to a bug.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> Be aware that there was a bug in MmGetSystemRoutineAddress if called

for an export that does not exist on older OS releases; see
http://www.osronline.com/article.cfm?article=494 for more details.

Well, not details in any sense to aspire to, but certainly a handy summary
of what had become known from assorted observations.

To trigger the bug discussed there, the sought routine needs not only to be
missing from the kernel and HAL on the running system but also (in practice)
to be alphabetically lower than ExAcquireFastMutex. This bug lasted up to
and including Windows XP SP2 and the original Windows Server 2003.

Another bug is not yet corrected. It applies only to ExAcquireFastMutex,
ExReleaseFastMutex and ExTryToAcquireFastMutex, and only then on x86 builds
starting from Windows Server 2003 SP1. This bug doesn’t cause
MmGetSystemRoutineAddress to crash Windows, just to return a bogus address
(so that someone else can crash Windows).

Geoff.

> to be alphabetically lower than ExAcquireFastMutex.

Alphabetically lower then the first HAL’s function IIRC.

Another bug is not yet corrected. It applies only to ExAcquireFastMutex,
ExReleaseFastMutex and ExTryToAcquireFastMutex

What is the need to ever query the addresses of these good old kernel functions?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maybe (and this is just a guess) because AFAIK on 64-bit vs 32-bit they’re implemented in HAL vs NTOS. So it could be a really sleazy way of handling that difference.


Best regards,
Alex Ionescu

Thank you, Maxim, confirming Ken’s response.

Thanks, Geoff. I’ve previously enjoyed one of your web-sites and now have had the pleasure to enjoy your response. What you describe seems quirkier than what I’d dug up about the subject. Fortunately, I won’t be looking for the functions you pointed out in your last paragraph, and that Maxim and Alex – hello, Alex – briefly discussed.

I post here today because I’m about to embark on creating a wrapper which does DbgPrint() for Windows 2000 and DbgPrintEx() for above, and wished to review this nice thread… I was startled when Windows 7 wasn’t debug-printing anything (due to my use of DbgPrint).

Have a nice day, folks.