Mais um blog inútil.

Agosto 14, 2008

Import Library for RtlGenRandom

Filed under: Coding,Drama,Serious Business,Useless,Windows — dongs @ 15:19

Everyone needs cryptographically strong pseudo random numbers in this day and age. From card games to your Paypal HTTPS session, it has become an essential part of secure systems. Now, as a user it's hard to generate randomness; we all know how many systems are seeded with time(NULL) or the like. That's why most operating systems have mechanisms to provide randomness to the user. In Unix systems, this is usually done through /dev/?random; on Windows, through the function CryptGenRandom.

However, CryptGenRandom requires a handle to a CSP (acquired by calling CryptAcquireContext). If all we want is random bytes, this no good; a full-fledged CSP takes too many resources (and time to load) for the task at hand. So an alternative is to use the lower level function RtlGenRandom, which doesn't require a CSP context. This name is an actual alias for the function 'SystemFunction036' in advapi32.dll. MSDN reports: "This function has no associated import library. This function is available as a resource named SystemFunction036 in Advapi32.dll. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Advapi32.dll". But what if we don't want the pain of loading and unloading libraries at runtime? I'll show you how to make the required import library to avoid this.

The main problem you will encounter  is that RtlGenRandom's calling convention is __stdcall, whereas its actual name in advapi32.dll does not reflect that (__stdcall functions have the number of bytes passed as parameters in the stack appended in the function name. In this case, it expects SystemFunction036 to be called SystemFunction036@8). Using the LIB utility doesn't help, even when using aliases: it always expects the appended number of bytes to be there. So first idea is to use function ordinals. Running DUMPBIN /EXPORTS on advapi32.dll shows us:

621  26C 00008292 SystemFunction036 = _SystemFunction036@8

So now we know the ordinal of our function: 621. With this in mind, we can now use LIB to create a .lib to link against our application. First, create a .def file with the following lines:

LIBRARY advapi32.dll
SystemFunction036@8 @ 621

Now run:

lib /DEF:RtlGenRandom.def /OUT:RtlGenRandom.lib /MACHINE:X86

Now you can just link the resulting .lib with your application to have the desired result.

However, this is not a good solution. Ordinals are by no means fixed (unless you're dealing with Winsock2 or MFC dynamic libraries) and you have no guarantee they'll be the same across Windows versions. So here's another way to do it. First, create a C source file and declare an empty function equal to RtlGenRandom:

#include <windows.h>
#define RtlGenRandom SystemFunction036
#define DLLEXPORT 	__declspec(dllexport)

Now create a .def like the following:

LIBRARY advapi32.dll

Now we compile the source and feed the DEF to the linker:

cl dummy.c dummy.def

The actual binary output of this compilation is irrelevant; what we want is the resulting dummy.lib. You can now link against this import library and it will link to the real advapi32.dll, thus giving us what we want. I used the following test source to try it out:

#include <stdio.h>
#include <windows.h>

#define RtlGenRandom                    SystemFunction036

int main(int argc, char **argv)
    BYTE blah[20];
    DWORD i;

    RtlGenRandom(blah, 20);

    for(i=0; i < 20; i++)
        printf("%02X ", blah[i]);

    return 0;

Compile with:

cl /O2 /MT test.c dummy.lib

Problem solved. Try it out.

PS: Someone's bound to comment "oh but Windows' PRNG is flawed, there was a paper on it some time ago". That's correct. However, both attacks (forward and backward security compromised) assume you already have knowledge of the whole state of the PRNG (i.e. you've owned the box) and that you're running a Windows previous to XP SP3, which fixed the issue.

Um comentário a “Import Library for RtlGenRandom”

  1. MuldeR diz:

    Note that "SystemFunction036" is not available in older Windows versions, which may or may not be relevant. Anyway, with your approach of using an import library, the EXE won't even launch on those older systems, just because the import "SystemFunction036" is missing from "advapi32.dll". The standard LoadLibrary() + GetProcAddress() at least has the advantage that you can fall back to something else, if "SystemFunction036" is missing - or at least display a meaningful error message to the user.

    BUT: Things are much easier, at least if you use MSVC. That's because the CRT of MSVC has a function rand_s(), which is nothing but a wrapper around "SystemFunction036" - it works 100% independant of rand() and srand(). Also the implementation of rand_s() in the CRT code takes care of LoadLibrary() + GetProcAddress() for you. And rand_s() will just throw an error, if "SystemFunction036" cannot be found...