I'm not sure i understand reflective loading.

An injector process allocates memory in the target, writes a stub and the dll binary to be loaded, and the stub calls ReflectiveLoad in that binary. ReflectiveLoad then does what the windows loader would do so that the dll is properly mapped and has access to the imports if needs.

What confuses me is, could the manual loading portion in principle be done by the injector, still achieving no dropped files? By this I mean reading the target's memory from the injector's process to figure out how the dll needs to be loaded in the target at the address of the allocated memory. Is it a matter of need or convenience? Why exactly has this choice been made?


Yes, it is possible to perform the necessary loading steps in the injector process (i.e., resolving the import addresses) before injecting the DLL, and some injectors/malware do that. See for example address 0x18007CD00 in my ComRAT IDB.

However, doing it that way is more cumbersome, as some of the neccessary DLLs might not already be loaded by the target process (nor the injector process). Therefore, you'd have to inject one or more threads into the target to load the imported DLLs before injecting. To get the addresses of the imported functions, you'd either have to load the DLLs in the injector process also (which should work, since Windows ASLR does not re-randomize the base addresses of a DLL that is already loaded, because the memory for the DLL will be shared), or you'd have to resolve the import addresses within the target process, hence more threads to create. Reflective loading bypasses this by forcing the DLL to load its own imports before beginning normal execution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.