Reply to thread

Message

<blockquote data-quote="Deleted member 65228" data-source="post: 663165">No problem. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite109" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />[SPOILER]CreateRemoteThread (from kernel32.dll) is commonly used however it won&#039;t be useful against a SYSTEM process (since SYSTEM is another user account), therefore you&#039;ll have to use at least RtlCreateUserThread (exported by ntdll.dll) if the target process is on another user account.[/SPOILER]You can write your own GetProcAddress(A/W) and LoadLibraryA(A/W) replacement for usage after code injection, which is typically the approach people take AFAIK. However, if you are injecting code into a process (no dependencies) and you need to access a function from a DLL not currently loaded within the process, you could always manual map it for stealth (so the DLL the injected code is now using is not found as a module within the process via normal module listing methods) instead of just using a normal LoadLibraryA/W replacement.You can also inject a structure containing addresses to functions if you are certain that the addresses are existent within the target process, and then access the addresses within the process you injected into.Happy malware testing!!</blockquote>

[QUOTE="Deleted member 65228, post: 663165"] No problem. :) [SPOILER] CreateRemoteThread (from kernel32.dll) is commonly used however it won't be useful against a SYSTEM process (since SYSTEM is another user account), therefore you'll have to use at least RtlCreateUserThread (exported by ntdll.dll) if the target process is on another user account. [/SPOILER] You can write your own GetProcAddress(A/W) and LoadLibraryA(A/W) replacement for usage after code injection, which is typically the approach people take AFAIK. However, if you are injecting code into a process (no dependencies) and you need to access a function from a DLL not currently loaded within the process, you could always manual map it for stealth (so the DLL the injected code is now using is not found as a module within the process via normal module listing methods) instead of just using a normal LoadLibraryA/W replacement. You can also inject a structure containing addresses to functions if you are certain that the addresses are existent within the target process, and then access the addresses within the process you injected into. Happy malware testing!! [/QUOTE]

Verification