Recently, I've been cracking a crackme DLL, and I need to inject it into a process, to see if it worked.
However, I've ran into a problem. I cannot seem to find how to debug DLL injection inside of ida. I've tried Debugger->Attach to Process, but that doesn't seem to work.
Any ideas?
One possibility: Insert a "code cave" into your hosting process, and let it load the DLL. For how to do it in a "generic" way in x64, look here. An important step of this is how to get the address of the kernel32.dll:
get_OS_DllAddresses: mov rax, gs:[60h] ; PEB mov rax, [rax + 18h] ; PEB::Ldr mov rax, [rax + 20h] ; PEB::Ldr.InMemoryOrderModuleList mov rax, [rax] ; 1st entry mov r15, [rax + 20h] ; ntdll.dll base address! mov rax, [rax] ; 3nd entry mov rax, [rax + 20h] ; kernel32.dll base address! ret PEB → PEB::Ldr → walk the InMemoryOrderModuleList linked list (LDR_DATA_TABLE_ENTRY).
After running this snippet, you have in rax the address of kernel32.dll (correctly also in the case of ASLR), and in r15 the address of ntdll.dll.
If you study the example given in the above link, you learn how to extract the necessary LoadLibrary calls (for your DLL to be checked), and the GetProcAddress calls, in case your DLL exports API calls.
A simple way to get the "shellcode" bytes is to make a little Assembler project e.g. in VisualStudio and let it create the binary code for you.
InMemoryOrderModuleList, then seem to proceed with the InInitializationOrderLinks? Not that I'm saying that this can't be done, but isn't this relying a bit too much on empirical data? InLoadOrderModuleList always has your.exe -> ntdll.dll -> kernel32.dll -> kernelbase.dll, but the memory order technically depends on the base address. dynamic debugging for dll you should use x64dbg or ollydbg. both can load dll to execute and debug.
