3 ms·

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

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!

Const-me 5y ago
> 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.
- wila 5y ago
  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.
  - Const-me 5y ago
    See this answer for slightly more info https://stackoverflow.com/a/54855964/126995 https://stackoverflow.com/a/54855964/126995 Just don’t use `LoadLibraryA` like the OP, that API is only there for compatibility with software written for Windows 95/98/Me. Use UTF-16 encoding for the path instead, and `LoadLibraryW` function for the remote thread address.
    - HuskyHacks 5y ago
      This is all fantastic info and I will likely fold this into the next post in the series about maldev with Nim. Thank you for linking to the StackOverflow page!
    - wila 5y ago
      Yes, that makes perfect sense. With ANSI/OEM encoding you will have problems eventually. Also thanks for the link, some good tips in there too.

Const-me 5y ago

> 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.

wila 5y ago
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.
- Const-me 5y ago
  See this answer for slightly more info https://stackoverflow.com/a/54855964/126995 https://stackoverflow.com/a/54855964/126995 Just don’t use `LoadLibraryA` like the OP, that API is only there for compatibility with software written for Windows 95/98/Me. Use UTF-16 encoding for the path instead, and `LoadLibraryW` function for the remote thread address.
  - HuskyHacks 5y ago
    This is all fantastic info and I will likely fold this into the next post in the series about maldev with Nim. Thank you for linking to the StackOverflow page!
  - wila 5y ago
    Yes, that makes perfect sense. With ANSI/OEM encoding you will have problems eventually. Also thanks for the link, some good tips in there too.