By Jeff White (karttoon)

Meanwhile, in the land of x86 assembly...

Whether you play in the malware, exploit, research, hobbyist, or programmer space - at some point you've encountered the age-old problem of locating a function address. I can't count how many times I've stepped through code that does exactly this, but I've always taken it for granted. To truly understand how it works, I wanted to get my hands dirty and re-create the wheel so-to-speak. Throughout this blog, I'll piece together shellcode I write and explain why, or what, is happening at each phase while identifying a specific DLL (kernel32) and finding the address of a specific function (LoadLibraryA) inside of it.

Before starting on this, I read a lot of articles on the subject and, while there is a ton of information out there, I kept finding myself scratching my head at one piece or another. How did they jump from A to B? Their debugger (nicely) tells them the values here but where is it getting them from? How the hell did this guy get the address of the function before even finding it in the first place?!

I was left with incomplete pictures of the process and this basically summed up my experience after a few hours.

This won't be new information for people but maybe if someone finds him or herself in the same boat as me, they'll get something out of having it all together.

Alright, to reiterate the goals of this post - identify the address of the LoadLibraryA function inside of kernel32.dll regardless of the OS we're running on. I say that last part only because for earlier versions of Windows OS the kernel32 DLL is located at known locations, so you didn't really need to "hunt" for it. I will keep the shellcode free of null-bytes and I'll refrain from placing the strings "LoadLibraryA" or "kernel32" in the shellcode directly because...why not?

*EDIT - 15NOV2016*
User @AsselmanT pointed out that on Windows 10 the kernel32 dll name is in all uppercase and thus this shellcode won't work on that version.

Thread Information Block (TIB)

Our first step is to find the address of the Process Environment Block (PEB) by using the Thread Information Block (TIB), which is a structure that stores information about the currently running thread. The PEB will contain additional structures, which will allow us to locate the address of kernel32.dll. The structure for the TIB is below, up to the item we're interested in.

At FS:[0x30] we can see there will be a 4 byte pointer to the address of the PEB. You can find the address of the TIB by looking in a debugger for the base address stored in the FS register, then look at offset 0x30 for the address of the PEB structure.

Based on the screenshot above, we can see that the TIB is located at 0x7FFDF000 and at 0x7FFDF030 is the address of the PEB - 0x7FFD3000. I'll write the shellcode in sections as each piece is covered and then combine it together at the end.

Now, you could just reference this offset by placing 0x30 into the MOV command instead of the push/pop into EBX, but this would also introduce 2 null-bytes, which we want to avoid.

Process Environment Block (PEB)

Within the PEB structure, I'm after the PEB_LDR_DATA address, which is the 7th element in the structure and contains data about the loaded modules for the process. Another useful piece of data is the base image address but I won't be using it here (think quick way of getting base address for offsets during exploitation) that is located at 0x08 from the PEB base address.

The pointer to the PEB_LDR_DATA structure is located at 0x0C offset from the PEB base address.

At 0x0C is our pointer to the PEB_LDR_DATA structure so we can add that value to the current base address of the PEB to get the address of the next structure - 0x778D7880.

PEB_LDR_DATA

The PEB_LDR_DATA structure most importantly contains the addresses for various lists of the loaded modules.

The lists contain the same information but are sorted in different orders (eg sorted according to memory order or the order in which they were loaded). Since we're interested in kernel32.dll, we can iterate over one of the lists until we find the entry for the DLL.

I picked the InLoadOrderModuleList list, which is doubly-linked, to find the module. Again, we'll add 0x0C to the base address of the PEB_LDR_DATA structure to get the list RVA.

At 0x778D788C we find the pointer to the first entry of InLoadOrderModuleList at 0x3C1BB0 and store that in EBX.

LDR_MODULE

As already mentioned, the LDR_MODULE structure contains a doubly-linked list. Effectively, you'll have a "forward" and "backward" link to each item in the list.

In the EBX register is the RVA to the first entry in the list, which holds a RVA/pointer to the address of the next module in the list. The main items of interest here are the BaseAddress and BaseDllName.

It's probably worth mentioning that you can use a number of these entries for fingerprinting the DLL you're after, so if you didn't want to include the Unicode string "kernel32.dll" in your shellcode, you could compare image size, hash, time stamp, file path, etc. In the end, stepping through will make it obvious so the effort isn't always worth the reward but it depends on the intent and use case.

The below is what we find at the first entry in the linked list - 0x3C1BB0. Using the structure above, the first red highlighted box is the address for the next entry in the list (also highlighted) than the following 4 bytes is the pointer for the previous entry. In this case, the previous entry is the address we just had - 0x778D788C.

If you look at the second set of red boxes, you will see that the forward link points to the next item on the list at RVA 0x3C1F68 and the back link points to the first entry at RVA 0x3C1BB0.

The green boxes show the base address for the modules and the blue box shows the pointer to the address of the module name, which is stored in Unicode. A quick look at RVA 0x3C1A4C shows "calc.exe" and at 0x77868328 we see "ntdll.dll". Looking at the Executable Modules also confirms the base address of 0x77800000 for this module.

To tie all of this together now with some shellcode we can iterate over each item in the list and compare the Unicode name found at RVA 0x30 from the beginning of the entry to "kernel32.dll".

Normally you could just include a null terminated Unicode string of the module name to compare against, but since one of the goals is to avoid that, we can mix things up a bit. Instead, lets make three comparisons at various offsets in the string to check against the module name. If they don't match at any of the three checks, the code will reset and move onto the next module.

The three offsets we want to compare against are 0x00, 0x08, and 0x10. Below is the shellcode to tackle this, along with some comments to help explain each piece.

When we run this, it iterates over module "calc.exe", then "ntdll.dll", and finally "kernel32.dll". At the end, the EBX register points to 0x3C1F68, which was the starting value for the third entry in the linked list shown previously. We can verify this by double-checking the entry.

Now that EBX holds the address for the list entry for kernel32.dll, we can grab the base address at offset 0x18.

Export Address Table (EAT)

With the base address in hand, the next step is to parse the kernel32.dll PE header structure for the Export Address Table (EAT) structure location. First things first, we need to determine the RVA to the PE structure by looking at the offset held in the DOS header structure.

We can see at 0x3C the offset to the PE header is stored in the DOS header.

So at the base address for kernel32.dll, plus the value found at 0x7614003C (0xF0), is the start of the PE header.

At RVA 0x78 from the PE header we can see the RVA for the EAT.

The EDX register now holds our RVA for EAT, 0xBF4C4.

Function Resolution - Arrays of days

Now that we have the location for the export table, we need to iterate through the three contained arrays - specifically, the AddressOfFunctions, AddressOfNames, and AddressOfNameOrdinals arrays. This part jumps around a bit but stick with me here.

The AddressOfNames (32-bit) and AddressOfNameOrdinals (16-bit) arrays are effectively linked. Each index in both array correspond to the other; AddressOfNames[0] is directly tied to AddressOfNameOrdinals[0]. AddressOfNames will contain offsets to the ASCII string name of the function, whereas AddressOfNameOrdinals will contain the corresponding functions index number in the AddressOfFunctions array. The entries in AddressOfFunctions contain RVA's for the functions starting address. To throw one more wrench into it, we have to take into account the nBase value found in the EAT, as it needs to be added to the ordinal value; this is done to align the index in the array, as the programmer doesn't have to start it at the first ordinal.

To show how this works, I'll step through resolving some names to function addresses. In the below image, the Base value is in red, the offset for the AddressOfFunctions table is in green, the offset for the AddressOfNames is in blue, and the offset for the AddressOfNameOrdinals is in purple.

The first 64 bytes of each of the arrays follow.

If we look at the first entry in the AddrName array, 0xB850F, and add it to the base address for kernel32.dll, we see the name of the function at 0x761F850F - AccquireSRWLockExclusive.

Looking at the corresponding first entry in the AddrOrd array we see the ordinal value 0x02. Adding the nBase of 0x01 gives us the value 0x03. We can see that AddrName[0] == AccquireSRWLockExclusive and AddrOrd[0] == 0x03, meaning that in AddrFunc[2] we have RVA 0xBEDC7, which gives us address 0x761FEDC7.

This one is probably a bad example because instead of finding the function RVA, we find another ASCII name that tells us this function was imported from NTDLL. This won't be accounted for this in the shellcode but if we did, we'd need to follow the same process of finding this new name in AddrName and the accompanying ordinal to get the function address.

Picking a different one, at AddrName[2] we have RVA 0xB853C which gives the address 0x761F853C and a function name of ActivateActCtx.

At AddrOrd[2] is 0x04, then adding the nBase value, we're left with 0x05. The 5th element in the above 64 bytes of AddrFunc is RVA 0x45911, which gives the address 0x76185911. A quick double-check of the Names in kernel32 confirms this is accurate.

Sweet! Almost there...

This is the breakdown of tasks that we now need to accomplish with the shellcode.

• Iterate over the AddressOfNames array until we find LoadLibraryA
• Determine its index in the array
• Look-up that index in the AddressOfNameOrdinals
• Take result ordinal and add the nBase number
• Use new value as index in AddressOfFunctions to get function RVA

The shellcode will be split into three checks, similar to the module name check. Luckily, the ASCII string "LoadLibraryA" lends itself to us nicely since it's exactly 12 bytes long.

Letting this run, ECX will be the address of our sought after function.

The last part of that shellcode might be a little confusing and, admittedly, took me a little bit to wrap my head around so I'll use a quick example with the previous ActivateActCtx function to demonstrate what's happening.

When we find ActivateActCtx, which is the 3rd element in the list, ECX will equal 0x03 due to us advancing ECX for the next element since we assume the comparison will fail. As our counter for ECX needs to start at 0 so we can get the correct offset during the multiplication of the index, it means that 0x03 will be the 4th element in the array starting at 0, thus we simply move back one index with the first DEC ECX instruction.

Looking at the first 64-bytes of AddrOrd we can see that at +0x04 into the array, we have the ordinal 0x04. To this, we add the nBase value of 0x01 so we end up with 0x05. To get the 5th element in the AddrFunc array, we need to decrease ECX again to account for the array starting at 0.

Then simply applying that offset to AddrFunc address will give you the RVA to the ActivateActCtx function.

That's a wrap

With that, we've got our address and can go on doing whatever we want. While not the most efficient way, especially given the way I decided to do the 3 checks for the module and function names, it works as expected, contains no null-bytes, and clocks in at 189 bytes.

Final shellcode:

Shellcode bytes:

Older posts...