{"id":1650,"date":"2015-07-03T23:25:51","date_gmt":"2015-07-04T03:25:51","guid":{"rendered":"http:\/\/www.ikriv.com\/blog\/?p=1650"},"modified":"2017-09-20T23:31:57","modified_gmt":"2017-09-21T03:31:57","slug":"win32-who-loads-the-library-that-implements-loadlibrary","status":"publish","type":"post","link":"https:\/\/ikriv.com\/blog\/?p=1650","title":{"rendered":"Win32: Who loads the library that implements LoadLibrary?"},"content":{"rendered":"

I was sitting in a Dairy Queen<\/a> this afternoon thinking about random stuff and suddenly this question hit me: who loads the library that implements LoadLibrary<\/font><\/code><\/a>? Isn’t it some kind of chicken-and-egg situation?<\/p>\n

Short answer<\/b>: It’s the loader<\/a>.<\/p>\n

Longer answer<\/b>: Win32 executable contains a list of DLLs and functions it needs to import. When creating a running process, the loader locates these DLLs, brings them into memory, finds requested functions, and puts their addresses in a well known place. This is done before passing control to the executable’s entry point. From the executable’s point of view when it starts running, the DLLs are already there. If the process wishes to load more DLLs at a later stage, it includes kernel32.dll!LoadLibrary<\/code> in the list of imports and calls this function when necessary.<\/p>\n

Really long answer<\/b>. Windows executable format specification (.DOC file)<\/a> defines an Import Directory Table (section 6.4.1), which is a linked list of DLL names. For each imported DLL there is an array of function names called Import Lookup Table (section 6.4.2) and array of their addresses called Import Address Table (section 6.4.4). See also a pretty picture from Google Code (PDF)<\/a>. When the operating system loads the executable file into memory, it scans the Import Directory Table, loads requested DLLs (and their imports, recursively), finds requested names inside those DLLs and puts their addresses in the Import Address Tables. This code is baked into the loader and does not invoke LoadLibrary<\/code>.<\/p>\n

To use LoadLibrary<\/code>, the executable needs to have an Import Directory Table entry for kernel32.dll<\/code>, and then an entry for LoadLibrary<\/code> in its Import Lookup Table. The loader will kindly put LoadLibrary<\/code>‘s address in the corresponding entry of the Import Address Table.<\/p>\n

However, if you inject<\/i> external code into the process (for the purpose of monitoring, debugging, or some malicious activity), that code will have harder time to find LoadLibrary<\/code>, since it doesn’t know in advance which entry in Import Address Table contains LoadLibrary<\/code>‘s address. In fact, LoadLibrary<\/code> may not be in that table at all. Fortunately, kernel32.dll<\/code> is loaded into every Win32 process, and LoadLibrary<\/code> is guaranteed to be inside it, so you only need to find where it is. Your first task is to determine the base address of kernel32.dll<\/code>. Apparently, on versions of Windows prior to Windows 7 it is the second DLL in the Import Directory Table, but on Windows 7 and later it is the third. A number of articles on the Internet describe how to implement the look up in a portable manner, e.g. http:\/\/www.ragestorm.net\/blogs\/?p=369<\/a>. Many mention “skypher.com<\/a>“, but that link is now dead. Once you’ve found the location of kernel32.dll<\/code>, you’ll have to traverse its “export” tables to find LoadLibrary<\/code>. This is what system call GetProcAddress<\/code><\/a> would do, but your injected code doesn’t yet know where to find GetProcAddress<\/code>. Fear not, there is a customized implementation of GetProcAddress<\/code><\/a>, but use it at your own risk.<\/p>\n","protected":false},"excerpt":{"rendered":"

I was sitting in a Dairy Queen this afternoon thinking about random stuff and suddenly this question hit me: who loads the library that implements LoadLibrary? Isn’t it some kind […]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[4,18],"tags":[],"class_list":["entry","author-ikriv","post-1650","post","type-post","status-publish","format-standard","category-hack","category-win32"],"_links":{"self":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1650","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1650"}],"version-history":[{"count":1,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1650\/revisions"}],"predecessor-version":[{"id":2436,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1650\/revisions\/2436"}],"wp:attachment":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1650"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1650"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1650"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}