Stack Overflow Note 1.6 address problem (1)

In the previous shellcode, I used a hard-coded address on my XP machine. It is not a good idea to use hard-coded addresses in shellcode at any time, similar to the relocation of dynamic libraries, which will almost certainly fail once the system environment and program compilation settings have changed. Therefore, we need to find a better way.

In the previous shellcode, I used the following hard-coded addresses, which have the following meanings:

Among them, the role of LoadLibraryA is very special, we use it to load the User32.dll library.

Now we're going to replace these hard-coded addresses. So, how do you get the addresses of these API functions? Get function address in dynamic link library There is a special function--getprocaddress, the prototype of this function is as follows:

/*****************************************************************************/farproc WINAPI GetProcAddress (_in_Hmodule hmodule,_in_LPCSTR lpprocname);*****************************************************************************/

The first parameter of this function is the handle of the module, which can be called LoadLibraryA, and the second argument is the function name. In this way, both MessageBoxA and exitprocess can use this method to obtain. But this relies on two functions: LoadLibraryA and GetProcAddress, and how do you get the addresses of the two functions?

Both of these functions are located in Kernel32.dll,kernel32.dll and will certainly be loaded without our own loading. So the question now is how to find the addresses of LoadLibraryA and GetProcAddress from Kernel32.dll?

Next you need a bit of knowledge of the Windows kernel and PE file format. We know that Kernel32.dll is a dynamic link library in PE format, the function to be exported is placed in the export table of PE file, so in order to get the address of LoadLibraryA and GetProcAddress, we need to parse Kernel32.dll export table manually. But before we do, we need to know the location of Kernel32.dll in memory, which is the base address of Kernel32.dll. Therefore, the problem is summarized as follows:
(1) How to obtain the base address of Kernel32.dll?
(2) How do I find the addresses of LoadLibraryA and GetProcAddress in the Kernel32.dll export table?

First to solve the problem. We know that when a process runs, in addition to loading the EXE file, the dependent. DLL is mapped to the virtual address space of the process, and the loaded DLLs are also the property of the process, so the process saves their information. The information for the process is stored in the PEB structure, where LDR (offset is 0xc0) points to a peb_ldr_data structure, which holds the information that the process has loaded the module. This structure is as follows:

/*****************************************************************************/typedef struct_peb_ldr_data{ULONG Length;   +0x00 BOOLEAN Initialized;            +0x04 PVOID Sshandle;      +0x08 List_entry inloadordermodulelist;    +0x0c List_entry inmemoryordermodulelist;    +0x14 List_entry ininitializationordermodulelist; +0X1C} PEB_ldr_Data,*ppeb_ldr_DATA; +0x24/*****************************************************************************/

Windows does not fully expose (document) this structure. This is the online version, we can also come through WinDbg, this is the structure on my XP SP3 machine:

Figure 37

This structure focuses on the following three linked lists: Inloadordermodulelist, Inmemoryordermodulelist, and Ininitializationordermodulelist. From the name point of view, these three queues are module linked list, the first one is in order of loading, the second is the location in the virtual space, the third is in the order of initialization. The second one is easy to understand, but what is the difference between the first and the third one?

We're going to use ininitializationordermodulelist, which hangs into the list of ldr_data_table_entry, which means that each loaded module corresponds to a ldr_data_table_entry, The structure is as follows:

/*****************************************************************************/typedef struct_ldr_DATA_table_ENTRY {List_entry inloadorderlinks; List_entry inmemoryorderlinks; List_entry ininitializationorderlinks; PVOID dllbase; PVOID entrypoint; DWORD Sizeofimage; unicode_string Fulldllname; unicode_string Basedllname; DWORD Flags; WORD Loadcount; WORD TlsIndex; List_entry hashlinks; PVOID Sectionpointer; DWORD CheckSum; DWORD TimeDateStamp; PVOID Loadedimports; PVOID Entrypointactivationcontext; PVOID patchinformation; }ldr_data_TABLE_entry,*pldr_DATA_table_ENTRY; /*****************************************************************************/

Again, on my machine:

The first three linked lists correspond to the three linked lists that the structure hangs on, with a focus on the fourth member, Dllbase, which is the base address of the load module. Therefore, we only need to follow the Ininitializationordermodulelist list to find the Kernel32.dll Pldr_data_table_entry, and then through its dllbase members, You'll know the address that Kernel32.dll loaded into. So which one kernel32.dll in the Ininitializationordermodulelist list? The safest approach is to parse Fulldllname members, which makes the code more complex. In fact, in a particular version of the system, the sequence of dynamic library initialization is certain, the first is Ntdll.dll, the second is Kernel32.dll. Vista the second is Kernelbase.dll, and the third one is Kernel32.dll. Therefore, you can avoid parsing fulldllname members.

Now we are going to find the PEB structure address of the process, the PEB structure is stored in the PEB member of the thread's TEB structure, and in the Windows system, the register FS always points to the teb of the current thread. Therefore, the entire process of acquiring the Kernel32.dll base site is as follows:

Figure 38

Before writing the code, take a look through the debugger in this order, I loaded with WinDbg is example_1, input:
D fs:[0x30] View the address of the current PEB:

Figure 39

Address is 0x7ffda000, enter:!PEB, verify:

Figure 40

is the same. Input: D 7ffda000+0x0c, view the address of the PEB_LDR_DATA structure:

Figure 41

Input: D 00251ea0+0x1c, view ininitializationordermodulelist linked list:

Figure 42

The List_entry structure is listed first, and Flink refers to the next node:

/*****************************************************************************/typedef struct_list_ENTRY {struct _list_entry *flink;struct _list_entry *blink;} LIST_entry, *plist_entry;/*****************************************************************************/

As a result, 0x00251f58 is the first element. Input: D 0x00251f58 View the following contents:

The base site is 0x7c920000, but the right is shown as Kernel32.dll??? is the first element not a ntdll.dll?

Take a look at the next element:

Base site for 0x7c800000, shown as Uer32.dll, there seems to be some problems, input!peb to see:

The base address and the name correspond to this.

Here's the code to get the Kernel32.dll base address:

/*****************************************************************************///Example_8 get Kernel32.dll's base address#include <stdio.h>Get Kernel32.dll's base address int get_kernel32_Base () {__asm    {mov eax, fs:[0x30]//PEBmov eax, [eax+0x0c]//Peb->ldrmov eax, [eax+0x1c]//Peb->ldr.ininitializationordermodulelist.flink (point to first Element)mov eax, [eax]//pointing to the second elementmov eax, [eax+0x08]//Kernel32.dll Base Address    }}int Main () {printf ("0x%x\n", Get_kernel32_base ());return 0;}/*****************************************************************************/

The results are as follows:

Figure 43

Here is a way to see other methods (including Windows 7):

Http://blog.harmonysecurity.com/2009_06_01_archive.html

Stack Overflow Note 1.6 address problem (1)