Closed weizn11 closed 2 years ago
Looks to be an issue with the ordering of arguments on the stack prior to LoadDLL
being called, at least since the new SRDI_PASS_SHELLCODE_BASE
option was added. dwFlags
is getting the shellcode address, resulting in the loader landing on line 427 (call to Sleep()
) and sleeping for an extended period even when no sRDI options are set (dwFlags
expected to be 0
). Swapping the order of pvShellcodeBase
and dwFlags
parameters in the LoadDLL
definition seems to be a quick fix, but haven't extensively tested it:
ULONG_PTR LoadDLL(PBYTE pbModule, DWORD dwFunctionHash, LPVOID lpUserData, DWORD dwUserdataLen, DWORD dwFlags, PVOID pvShellcodeBase)
Looks to be an issue with the ordering of arguments on the stack prior to
LoadDLL
being called, at least since the newSRDI_PASS_SHELLCODE_BASE
option was added.dwFlags
is getting the shellcode address, resulting in the loader landing on line 427 (call toSleep()
) and sleeping for an extended period even when no sRDI options are set (dwFlags
expected to be0
). Swapping the order ofpvShellcodeBase
anddwFlags
parameters in theLoadDLL
definition seems to be a quick fix, but haven't extensively tested it:
ULONG_PTR LoadDLL(PBYTE pbModule, DWORD dwFunctionHash, LPVOID lpUserData, DWORD dwUserdataLen, DWORD dwFlags, PVOID pvShellcodeBase)
Yes, it looks like swapping parameters fixes this issue, thx~
When my program runs to this line of code, it takes a long time to return:
HMODULE hLoadedDLL = (HMODULE)rdi();
It's been running here for too long, what is the reason for this?