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:
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)
DLLEXPORT BOOLEAN WINAPI RtlGenRandom(PVOID in, ULONG len) {}
Now create a .def like the following:
LIBRARY advapi32.dll
EXPORTS
SystemFunction036
Now we compile the source and feed the DEF to the linker:
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
BOOLEAN WINAPI RtlGenRandom(PVOID, ULONG);
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.
