Nim on the Attack: Process Injection Using Nim and the Windows API
1–10 of 22 posts
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#2I wonder why people are writing shell codes for that?
When I need to inject my code into another process, I write a DLL and only inject LoadLibrary function call. Much more reliable this way: the OS applies relocation table, I have C and C++ runtimes in the injected code, the result is compatible with ASLR, if my DLL has other DLL dependencies the OS will load them first, etc.
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#3I wonder why people are writing shell codes for that? When I need to inject my code into another process, I write a DLL and only inject LoadLibrary function call. Much more reliable this way: the OS applies relocation table, I have C and C++ runtimes in the injected code, the result is compatible with ASLR, if my DLL has other DLL dependencies the OS will load them first, etc.
What exactly do you mean by compatible with ASLR? And would you mind going into a little detail on how injecting a DLL works, compared to what's being done here?
Sorry to bother, just very interested in this stuff!
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#4I wonder why people are writing shell codes for that? When I need to inject my code into another process, I write a DLL and only inject LoadLibrary function call. Much more reliable this way: the OS applies relocation table, I have C and C++ runtimes in the injected code, the result is compatible with ASLR, if my DLL has other DLL dependencies the OS will load them first, etc.
What exactly do you mean by compatible with ASLR? And would you mind going into a little detail on how injecting a DLL works, compared to what's being done here? Sorry to bother, just very interested in this stuff!
> What exactly do you mean by compatible with ASLR?
The code being injected doesn't need to hardcode any absolute addresses of the dependent functions. It works fine when the OS kernel randomizes virtual addresses of all DLLs.
> how injecting a DLL works, compared to what's being done here?
Very similar, the main difference is what's injected.
The OP is injecting code and running it. The injected code needs to be position-independent, in practice this means it needs to be written in assembly, which is very hard to do for non-trivial things.
I normally use VirtualAlloc to allocate a UTF-16 buffer for the path of a DLL I made, then use CreateRemoteThread to run LoadLibrary function.
This way I can use normal C++ with all the features in the code being injected.
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#5I wonder why people are writing shell codes for that? When I need to inject my code into another process, I write a DLL and only inject LoadLibrary function call. Much more reliable this way: the OS applies relocation table, I have C and C++ runtimes in the injected code, the result is compatible with ASLR, if my DLL has other DLL dependencies the OS will load them first, etc.
One reason (not the only one) is if you write a DLL then you need an EXE to be able to spawn it on-demand. That results in 2 files to deal with which is rather inconvenient. Actually 3 files if you want to be both x64- and x86-compatible.
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#6I wonder why people are writing shell codes for that? When I need to inject my code into another process, I write a DLL and only inject LoadLibrary function call. Much more reliable this way: the OS applies relocation table, I have C and C++ runtimes in the injected code, the result is compatible with ASLR, if my DLL has other DLL dependencies the OS will load them first, etc.
One reason (not the only one) is if you write a DLL then you need an EXE to be able to spawn it on-demand. That results in 2 files to deal with which is rather inconvenient. Actually 3 files if you want to be both x64- and x86-compatible.
Almost all production-quality software I’m making needs multiple executable files anyway, and uses an installer. For Windows, usually this one https://wixtoolset.org/
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#7Earlier quoted context omitted.
One reason (not the only one) is if you write a DLL then you need an EXE to be able to spawn it on-demand. That results in 2 files to deal with which is rather inconvenient. Actually 3 files if you want to be both x64- and x86-compatible.
Almost all production-quality software I’m making needs multiple executable files anyway, and uses an installer. For Windows, usually this one https://wixtoolset.org/
Sure, and in your case you might not need something like this this.
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#8Earlier quoted context omitted.
Almost all production-quality software I’m making needs multiple executable files anyway, and uses an installer. For Windows, usually this one https://wixtoolset.org/
Sure, and in your case you might not need something like this this.
Sometimes I do. Microsoft has not made CreateRemoteThread API to support malware, it has many legitimate uses.
For instance, one time a client wanted to have a functional equivalent of desktop duplication API working on Windows 7. I wrote a DLL that’s injected into dwm.exe, hooks IDXGISwapChain.Present and ResizeBuffers methods, copies video frames into another D3D texture, and uses DXGI surface sharing to feed frames in VRAM to the capturing/encoding process.
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#9I wonder why people are writing shell codes for that? When I need to inject my code into another process, I write a DLL and only inject LoadLibrary function call. Much more reliable this way: the OS applies relocation table, I have C and C++ runtimes in the injected code, the result is compatible with ASLR, if my DLL has other DLL dependencies the OS will load them first, etc.
[deleted]
Re: Nim on the Attack: Process Injection Using Nim and the Windows API
#10Earlier quoted context omitted.
What exactly do you mean by compatible with ASLR? And would you mind going into a little detail on how injecting a DLL works, compared to what's being done here? Sorry to bother, just very interested in this stuff!
> What exactly do you mean by compatible with ASLR? The code being injected doesn't need to hardcode any absolute addresses of the dependent functions. It works fine when the OS kernel randomizes virtual addresses of all DLLs. > how injecting a DLL works, compared to what's being done here? Very similar, the main difference is what's injected. The OP is injecting code and running it. The injected code needs to be pos…
That's a great idea!
I already know where I can use this, which would make my code a lot easier (and more robust) to write.
Thanks heaps.