I am trying to understand how malware loads a dll from memory, like from a resource section. I am seeing codes all over google but i cant find sort of a pseudocode like in simple english that can explain the process. I understand c++ and pe file format for most part, just can seem to make sense of how a dll can be loaded in memory.

  • basically what i am trying to understand is how malwares load dll without using api's in windows. I mean how does a custom loader load dlls?
    – jammy47
    Commented Dec 1, 2016 at 0:24
  • Malware authors use APIs all the time; why wouldn't they? If not using the LoadLibrary function, they still have to use open() and read(). They read the file into a buffer, they have to use a pointer into that buffer with an offset of their method in the file. But if they don't use LoadLibrary, they risk executable modules being blocked by DEP (see msdn.microsoft.com/en-us/library/windows/desktop/… ) Commented Dec 1, 2016 at 1:45
  • 1
    Reflective DLL Injection: blog.harmonysecurity.com/2008/10/…
    – void_in
    Commented Feb 23, 2018 at 4:44
  • A PE structure defines the binary and is stored within the file. If you were to build this structure in memory and then map your binary data to it header to hearder section to section you remove the requirement of having the dll on disk.
    – McMatty
    Commented Feb 27, 2018 at 1:27

2 Answers 2


First of all, malware normally does not load it's own DLLs into memory. I think you confuse this with malware injecting executable code into another process (OpenProcess(), WriteProcessMemory()) and starting a new thread in that process (CreateRemoteThread()) which executes that code. This has nothing to do with loading a DLL into memory which is much more difficult than just executing code. Why should malware consist of multiple DLLs that are loaded into memory? It is much easier to write ONE malware executable instead of multiple DLLs.

Back to your question: If you want to trick Windows to load a DLL from memory this is something between very advanced programming and cracking.

One disadvantage is that you cannot use debuggers if anything goes wrong in your DLL.

You can use for example this code: https://github.com/fancycode/MemoryModule to load a DLL into memory. I did not test it because the disadvantage is that you must use special funcions to access that DLL in memory afterwards. For example to read a string resource from that DLL you cannot use the usual Windows API. You must use a function from the same library.

Some problems that occur are listed in more detail here: https://www.codeproject.com/Tips/430684/Loading-Win-DLLs-manually-without-LoadLibrary The author says that with his code his DLL does not have an HINSTANCE handle. This is a big disadvantage.

  • Building all the code as a single exe prevents the flexibility an attacker would want. It also allows a single signature to built in AV products. Commerical malware is built up stages instead of a single drop file AV can pick up
    – McMatty
    Commented Feb 27, 2018 at 0:40
  • Interesting. Do you have a link with more information about that?
    – Elmue
    Commented Mar 8, 2018 at 14:38
  • Generic google link networkworld.com/article/2176480/network-security/…
    – McMatty
    Commented Mar 8, 2018 at 20:43

I'm not really too sure about what you're asking as to my knowledge the only way to work with the OS is calling its APIs documented and undocumented.

Here is what I consider the easiest way to understand the different injection attacks and it covers the some methods you were asking about

Ten Process Injection Techniques

Number 2 and 3 of the list describe processes that allow code injection without having the dll on disk both working with the PE structure.

Reflective injection builds the PE structure up in memory and then maps the binary code to it. With the PE structure and correctly mapped binary this is now essentially in memory and no library APIs have been called to load it from disk.

Process hollowing will unmap sections of a loaded dll suspended thread and then map in malicious code and repoint the execution point before the thread is set to run. Tried to get this working as a C# project but never got the rebase working :(

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .