Dynamically Extracting The Encryption Key From A Simple Ransomware

Posted Feb 18, 2022 Updated Jun 7, 2024

By 0x00Jeff 18 min read

recently I’ve played ransomware101 room in secdojo website where I was given a windows box that has a flag ecrypted by a ransomware, and I had to figure out the decryption key to recover it, the ransomware key generation function worked like the following:

get the computer name
get the mac address
concatenate them
md5

it generated the same key everytime for the same computer, so I wanted to see if I could use the built-in key generation function to dynamically extract the key from the ransomware

I had came up with 2 ways to do it, I had spent few days trying to get the first one to work, when I randomly stumbled upon another way, and was able to get it to work under 2 hours, I’m gonna touch on the second one first as it seems easier and more practical

first we need to make one piece of information known, my goal is to call the function in the ransomware that is responsible for generating the encryption keys. to do that I need to load the dll into my process, however the second I load it, its entry point will be called making it do its thing, which is encrypting my files

so basically what I was trying to figure out is a way to load the dll without its entry point/DllMain being called, I also wanted to make take this an opportunity to learn something new, so no manual mapping (not that it wouldn’t be a valid solution), and absolutely no patching on disk

second method : Dll Load notifications

according to the docs, LdrRegisterDllNotification lets you register a Dll callback that gets executed before the dynamic linking occurs, that is our callback function will be called everytime a dll is loaded/unloaded, before the Dll entry is called, which doesn’t happen until the callbacks function returns, this is perfect for this situations as it lets us do whatever we want the dll before it’s entry gets executed which is just what I need

now the plan is :

register a dll callback
load the ransomeware dll
when the the control is handed to the callback function, place a ret at the beginning of DllMain, this will make it return as soon as it’s called, while at the same time letting the entry point gets executed which causes the dll to correctly initialize
call the function responsible for generating the encryption keys

registering a dll callback

  
#define DLL_NAME		"r101.dll"
#define WIDE_DLL_NAME		L""DLL_NAME
...

    // Get a handle to ntdll
    HANDLE HNtdll = GetModuleHandleA("ntdll.dll");
    if(!HNtdll){
        fprintf(stderr, "couldn't Get a handle to ntdll.dll :(\n");
        return -1;
    }

    // get the address of LdrRegisterDllNotification
    LdrRegisterDllNotification f = (LdrRegisterDllNotification)GetProcAddress(HNtdll, "LdrRegisterDllNotification");
    if(!f){
        fprintf(stderr, "LdrRegisterDllNotification not found :(\n");
        return -1;
    }

    // register a dll callback
    PVOID cookie = NULL;
    if(f(0, LdrDllNotification, (PVOID)WIDE_DLL_NAME, &cookie) != STATUS_SUCCESS){
    	fprintf(stderr, "LdrRegisterDllNotification failed with error code = %ld\n", GetLastError());
    	return -1;
    }

first we get a handle to Ntdll.dll, check for the presence of LdrRegisterDllNotification in the said dll and resolve its address, then register a notification callback which will call the function LdrDllNotification that we’re going to cover in a bit, the callback function gets a pointer to the dll name we’re trying to patch as an argument

load the ransomeware dll

then we simply load the dll using LoadLibraryA this will cause our callback function to be called with generic info about the loaded dll, plus a pointer to the dll name we pass to it

  
  HMODULE Htry = LoadLibraryA(DLL_NAME);
  if(!Htry){
    fprintf(stderr, "couldn't find %s :(\n", DLL_NAME);
    return -1;
  }

patching DllMain

the signature of our callback should take the following form

  
VOID CALLBACK LdrDllNotification(
  _In_     ULONG                       NotificationReason,
  _In_     PCLDR_DLL_NOTIFICATION_DATA NotificationData,
  _In_opt_ PVOID                       Context
);

where upon loading a dll, NotificationReason has the value LDR_DLL_NOTIFICATION_REASON_LOADED, NotificationData is an _LDR_DLL_LOADED_NOTIFICATION_DATA struct containing the following info

  
typedef struct _LDR_DLL_LOADED_NOTIFICATION_DATA {
    ULONG Flags;                    //Reserved.
    PCUNICODE_STRING FullDllName;   //The full path name of the DLL module.
    PCUNICODE_STRING BaseDllName;   //The base file name of the DLL module.
    PVOID DllBase;                  //A pointer to the base address for the DLL in memory.
    ULONG SizeOfImage;              //The size of the DLL image, in bytes.
}

so each time the callback function is called, it gets the Dllname, DllPath, the address where the dll is loaded, its size, and a Context pointer, which is an argument we control, in this case it’s the name of the dll we want to patch

now we just calculate the address of DllMain with the next steps so I can patch it

open the dll is disassembler of your choosing (mine is ida)
rebase the program to 0
go to dllMain and check its offset

we end up with the offset value 0x2600

this means that if you know where the dll is loaded in memory, if you added 0x2600 to that address, you get the address of DllMain. now as mentioned before, our callbcks function gets this peace of information every time a dll is loaded, here’s what the callback function looks like

  
#define DLL_MAIN_OFFSET 0x2600
...
VOID CALLBACK LdrDllNotification(
  _In_     ULONG                       NotificationReason,
  _In_     PCLDR_DLL_NOTIFICATION_DATA NotificationData,
  _In_opt_ PVOID                       Context
){

    PBYTE ptr;
    DWORD OldProtection;

    wchar_t *target_dll = (wchar_t *)Context;

    if(NotificationReason != LDR_DLL_NOTIFICATION_REASON_LOADED)
        return;

    if(wcscmp(target_dll, NotificationData -> Loaded.BaseDllName -> Buffer))
        return;

    ptr = NotificationData -> Loaded.DllBase;
    if(!VirtualProtect(ptr + DLL_MAIN_OFFSET, 1, PAGE_EXECUTE_READWRITE, &OldProtection)){
        fprintf(stderr, "VirtualProtect failed with code = %ld\n", GetLastError());
        return;
    }

    // make DllMain return as soon as it's called
    // so our files don't get encrypted
    *(ptr + DLL_MAIN_OFFSET) = 0xc3;
}

this function checks for the loaded dlls, compare their names with the dll we want to patch, makes the first byte at the DllMain writable so we can edit it, then writes a 0xc3 into it, this will make DllMain returs as soon as it’s called

call the key generation function

the function generating the keys is the second function that gets called inside StartRansomware(). in the same way we did before, we get the offset 0x20e0

the function takes no arguments, and returns a char pointer of to the encryption key. now all we have to do is declare a function pointer of the said type, make it point to our function, then call it and print the key

now if you remember the code that we used before to gets our callback function called

  
  HMODULE Htry = LoadLibraryA(DLL_NAME);
  if(!Htry){
    fprintf(stderr, "couldn't find %s :(\n", DLL_NAME);
    return -1;
  }

this puts the dll address in Htry, knowing the offset to the function we can do this

  
#define KEY_GENERATION_OFFSET 0x20e0

...
  key_gen my_key_gen = (key_gen)((PBYTE)dll + KEY_GENERATION_OFFSET);
  printf("key = %s\n", my_key_gen());

and this is the result we get

first method : patching ntdll

my initial thought of the process that I would have to go through was the following :

load the dll into my own process
call the key generation functions
profit

but this small list went a bit wrong as you’ll read here

loading the dll

this bit was the most time consuming to figure out. as the next parts would explain in the details the approaches that I took, and how did they miserably fail

first idea : LoadLibraryA

I had a dll I can practice on, all it did was displaying a message using MessageBoxW. the problem is, as soon as I loaded it using LoadLibraryA, a little message box popped, reminding me of the fact that the said function not only loads dlls into the process address space but also calls their entry point which eventually calls its DllMain causing the dll to do its thing, which in this case is, encrypting our files so this route wouldn’t work

second idea : LoadLibraryExA

this function is basically LoadLibraryA with additional loading options, one of those options is DONT_RESOLVE_DLL_REFERENCES which according to msdn docs does the following

If this value is used, and the executable module is a DLL, the system does not call DllMain for process and thread initialization and termination. Also, the system does not load additional executable modules that are referenced by the specified module.

I thought to my self “a function that doesn’t call DllMain, great!”. but I later found out that this wound’t work for 2 reasons

the first one according to the msdn docs is that this flag is used when one wants to access only data or resources in the DLL, this means that it won’t be executable, this however was a problem I could deal with by changing the memory protections

the other one which as the flag name DONT_RESOLVE_DLL_REFERENCES suggest is … yep, the function doesn’t resolve the references, including the function imports, but what does this mean ?

in a normal scenario, your dll calls a function, MessageBoxW in my case. the OS loader makes sure the function exists in memory by loading the dll that contains it, it also ensures that your dll is calling the right address at which the said function resides. in other words, the OS loader got your back

but when loading a dll with DONT_RESOLVE_DLL_REFERENCES, the function your dll tries to call doesn’t exist in memory, and by the time your dll tries to call the address where it’s supposed to be, it actually calls into a place filled with zeroes causing the program to crash (I had to learn this the hard way)

third idea : a deeper look into LoadLibraryA

by this time, I know using LoadLibraryExA with any special flags is wound’t work, but what about LoadLibraryA ? (btw LoadLibraryA is just a wrapper arround LoadlibraryExA, calling LoadLibraryA(libname) is the equivalent of calling LoadLibraryExA(libname, 0), the second argument being 0 means no speciall loading flags. the deal breaker is not really which function is being called, but the flags argument that ends up in LoadLibraryExA)

LoadLibraryA does everything I want to do, it loads a dll with the right memory protections and everything, it only does one thing that I don’t need, so why not try to get ride of it ? this was the time to reverse LoadLibraryA to figure out at which point it calls the dll’s entry point so I can patch it away

after some stepping over and out of functions, I’ve found the one responsible for calling the Dll EntryPoint and how it’s reached from LoadLibrary

LoadLibrary()	-> kernel32.LoadLibraryEx
		-> kernelbase.LoadLibraryExA
		-> kernelbase.LoadLibraryExW
		-> ntdll.LdrLoadDll
		-> ntdll.LdrpLoadDll (not exported)
		-> ntdll.LdrpPrepareModuleForExecution (not exported)
		-> ntdll.LdrpInitializeGraph (not exported)
		-> ntdll.LdrpInitializeNode (not exported)
		-> ntdll.LdrpCallTlsInitialiazers (not exported)
		-> ntdll.LdrpCallInitRoutine (not exported)
		-> call rsi (rsi has a function pointer pointing at the dll entry point)

(the function names can change between windows versions i.e I found that windows 10 has LdrpLoadDllInternal instead of LdrpLoadDll)

ntdll.LdrpCallInitRoutine was the function responsible for calling the Dll entry point by executing the following instructions

  
00007FF88EA6DCEA            | 4D:8BC6          | mov r8,r14
00007FF88EA6DCED            | 8BD3             | mov edx,ebx
00007FF88EA6DCEF            | 48:8BCF          | mov rcx,rdi
00007FF88EA6DCF2            | FFD6             | call rsi

where rsi is pointing to the DLl EntryPoint

now if we noped out those instructions the dll entry won’t be called, but that would happen for every dll that is being loaded which would cause the program to crash when trying to call functions from newly loaded dlls

so I tried hooking ntdll.LdrLoadDll since it’s the last exported function that gets the dll name. so my method was

- intercept the dlls being loaded
- if the dll name matches out target dll patch `ntdll.LdrpCallInitRoutine` so it doesn't call the entry point
- unpatch `ntdll.LdrpCallInitRoutine` so every other dll loads just fine

also the way I found where ntdll.LdrpCallInitRoutine is in memory for now, since it’s not exported, was the following, in my ntdll at least, the said function existed exactly 274 bytes after RtlActivateActivationContextUnsafeFast (a random function located right before the one I’m searching for), so I used GetProcAddress on the said function then calculated the address from there

so basically something like this

  
#define CALL_RSI_OFFSET 274
// the address of the call instruction that invokes the dll entry point in ntdll.LdrpCallInitRoutine 
PBYTE call_rsi;
PVOID MyLdrLoadDll;

int main(void){

	// Get a handle to ntdll
	HANDLE HNtdll = GetModuleHandleA("ntdll.dll");
	if(!HNtdll){
		fprintf(stderr, "couldn't find ntdll.dll :(");
		return -1;
	}

	// get the address of the `call rsi` responsible for calling the dll entry point
	PVOID base = (PVOID)GetProcAddress(HNtdll, "RtlActivateActivationContextUnsafeFast");
	call_rsi = (PBYTE)base + CALL_RSI_OFFSET;

	// get the address of LdrLoadDll
	MyLdrLoadDll = (_LdrLoadDll)GetProcAddress(HNtdll, "LdrLoadDll");
	if(!MyLdrLoadDll){
		fprintf(stderr, "couldn't find LdrLoadDll :(");
		return -1;
	}

	// hook LdrLoadDll
	hook((PVOID)MyLdrLoadDll, (PVOID)FakeLdrLoadDll);

and here’s my FakeLdrLoadDll function

  
NTSTATUS WINAPI FakeLdrLoadDll( PWSTR IN SearchPath,
		PULONG IN LoadFlags,
		PUNICODE_STRING DllName,
		HMODULE *BaseAddress){

	char *original_bytes = malloc(call_rsi_len * sizeof(char));
	if(!original_bytes){
		fprintf(stderr, "calloc failed with error : %ld\n", GetLastError());
		exit(EXIT_FAILURE);
	}

	BOOL IsTargetDll = !!wcscmp(WIDE_DLL_NAME, DllName -> Buffer);

	if(!IsTargetDll)
		patch(call_rsi, original_bytes);

	// un-hook LdrLoadDll
	unhook(MyLdrLoadDll);

	// invoke the unhooked LdrLoadDll
	if(MyLdrLoadDll(SearchPath, LoadFlags, DllName, BaseAddress))
		fprintf(stderr, "I couldn't load %ls :(\n", DllName -> Buffer);

	// re-hook
	hook((PVOID)MyLdrLoadDll, FakeLdrLoadDll);

	// unpatch
	if(!IsTargetDll)
		unpatch(call_rsi, original_bytes);

	free(original_bytes);

	// return True meaning the dll was sucessfully loaded
	return TRUE;
}

patch just put nops out the call rsi while unpatch puts the original bytes back

this ensures that every dll except our target one will have its entry point called causing it to be correctly initialized

then I simply loaded the dll

  
	dll = LoadLibraryA(DLL_NAME);
	if(!dll){
		fprintf(stderr, "couldn't load %s, error code = %ld\n", DLL_NAME, GetLastError());
		return -1;
	}

now that the dll resides in memory, I need to

put a 0xc3 at the first byte of DllMain so calling the dll entry point won’t encrypt my files
manually call the dll entry point so the Dll gets initialized
call the key generation function to get the key

patching DllMain

  
#define DLL_TO_DLLMAIN	0x2600
...
	DllMain MyDllMain = (DllMain)((PBYTE)dll + DLL_TO_DLLMAIN);
	PatchDllMain(MyDllMain);
...

void PatchDllMain(PVOID addr){
	DWORD whatever;

	if(!VirtualProtect(addr, 1, PAGE_EXECUTE_READWRITE, &whatever)){
		fprintf(stderr, "VirtualProtect failed with code = %ld\n", GetLastError());
		return;
	}

	// TODO : make the source match this line (deleted ptr var)
	*(PBYTE)addr =  0xc3;
}

calling the dll EntryPoint

  
#define DLL_TO_ENTRY	0x1C6AC
...

	DllEntry EntryPoint = (DllEntry)((PBYTE)dll + DLL_TO_ENTRY);
	EntryPoint(dll, DLL_PROCESS_ATTACH, NULL);

extracting the encryption key

  
	key_gen my_key_gen = (key_gen)((PBYTE)dll + KEY_GENERATION_OFFSET);
	printf("key = %s\n", my_key_gen());

result

ayo ???? why am I getting an access violation instead of the encryption key

this part threw me off a bit, every step was done just like it’s supposed to be, and I couldn’t make sense of what the problem was

I tried on a different dll that all it did was pop a message using MessageBoxW and was faced with the same result

what made it even confusing is the fact that the dll code was being called, and the access violation was happening inside a random internal function in ntdll (RtlAllocateHeap for the ransomware, and some other Nt* function that MessageBoxW calls into in the other one)

the solution was found by accident when I was trying different stuff to debug it. and for the dll that uses MessageBox was loading user32.dll before loading the test dll, this made no sense to me because

A. that dll was already in memory before I loaded my test dll
B. loading the test dll should cause any dll dependency to load as well

so I went to the ransomware dll, figured out what function was calling RtlAllocateHeap, it was GetAdaptersInfo, looked up what dll it’s located in (Iphlpapi.dll), loaded it before the ransomeware and …

again this made no sense to me because that dll was already in memory, I guess it’s something I might understand in the future

trying to generalize this solution

now everything is working fine and dandy, till you run it on a different computer, and you find out that call rsi isn’t really located at 274 bytes after RtlActivateActivationContextUnsafeFast anymore, or doesn’t exist at all (replaced by other variations of the call instruction). so I’ve tried exploring the possibility to making the solution as generalized as possible

my original bytes were like this

00007FF88EA6DCEA            | 4D:8BC6          | mov r8,r14
00007FF88EA6DCED            | 8BD3             | mov edx,ebx
00007FF88EA6DCEF            | 48:8BCF          | mov rcx,rdi
00007FF88EA6DCF2            | FFD6             | call rsi

and these are the bytes from another ntdll

00007FF88EA6DCEA            | 4D:8BC7          | mov r8,r15
00007FF88EA6DCED            | 8BD6             | mov edx,esi
00007FF88EA6DCEF            | 48:8BCE          | mov rcx,r14
00007FF88EA6DCEF            | 48:8BC4          | mov rax,r12
00007FF88EA6DCF2            | FFD6             | call rsi

I’ve noticed that most bytes are preserved between different versions, other ones only differ in a nibble or two (same instructions using different source registers), and other instructions that only exist in one version but not in another, so I made NibbleSigScan which is a simple program that allows you to wildcard nibbles, in the previous example, you can search for the pattern 0x4d, 0x8b, 0xc?, 0x8b, 0xd? and it will match the first 2 instructions in both versions

after checking other version, I’ve found 5 patterns and wrote signatures for them. I’ve tried the signatures on about 30 version of ntdll (shoutout to folks who send me their dlls!), and they worked on all of them, except for one from a lab I had with windows 7 installed, but I figured there is no point in sopporting that one

now this should work on most ntdll version, but it’s still advisable to run the second solution on a vm, incase there is a different version my sigatures don’t work against (there probably exist more than one). as for the first method, it will work like charm as it’s independent from the ntdll version

another route

instead of having to patch DllMain to return right away, then manually calling DllEntry to initliaze the dll. in case of dealing with a dll that follows the standards of checking the ul_reason_for_call argument, one could patch the Dll entry point to call DllMain with a value other than DLL_PROCESS_ATTACH to inititialize the dll without encrypting the files, or patch the intructions in DllMain that calls the main functionality in the Dll (i.e DllMain creating threads on other functions), but the one in hand didn’t

lastly

as this article comes to an end, I’d like to thank hakivvi and harrold for helping with ideas and and encouragement, as well as the bois who are always offering their help such as jlbana, drifter and many others

oh, and the rasomware as well as the code for the solutions can be found in this repo

peace out

OS Internals, Windows

This post is licensed under CC BY 4.0 by the author.

second method : Dll Load notifications

registering a dll callback

load the ransomeware dll

patching DllMain

call the key generation function

first method : patching ntdll

loading the dll

first idea : LoadLibraryA

second idea : LoadLibraryExA

third idea : a deeper look into LoadLibraryA

patching DllMain

calling the dll EntryPoint

extracting the encryption key

result

trying to generalize this solution

another route

lastly

Trending Tags