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.
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.
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
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 :(