4 ms·

Injecting code into another process is well supported :P 1) VirtualAllocEx some memory to hold the path to a DLL you want to inject. 2) WriteProcessMemory to

Injecting code into another process is well supported :P 1) VirtualAllocEx some memory to hold the path to a DLL you want to inject. 2) WriteProcessMemory to write the path to that memory. 3) CreateRemoteThread passing in the address of `LoadLibrary` and the pointer to the previously allocated memory. It's no coincidence that `LoadLibrary` has a signature which can directly be passed to `CreateRemoteThread`!

codedokode 5y ago
Isn't this a way to introduce bugs? For example: - injected DLL can change some process-related settings and break main program - injected DLL can call non-reenterable function from a system library simultaneously with main program
- bmm6o 5y ago
  No need to go that far. If you allow an untrusted process to write to your memory, you've already lost. One thing I haven't seen called out yet is that there is security associated with this API call - ordinary users can only call this on processes that they own. (And as far as the terminology, these aren't "bugs" since they aren't defects in the software.)
- barchar 5y ago
  I mean sure. If you can do this you can debug the process (how do you think debuggers are implemented?) and ofc once you're debugging a process you can introduce bugs and cause random havoc. Linux can do this too with ptrace. And mac has something similar I'm sure, you gotta be able to debug. Now, the target process can implement countermeasures against you, that's what anti-debug is, but it's impossible in the general case to defend yourself against a debugger with the same privilege level as you. (it is an arms race though, so sometimes it's easiest to resort to kernel-mode anti-anti-debug techniques even against pure user-mode anti-debug. If you do that you need to disable KPP, and you can't disable KPP in the supported way because the supported way is to attach a kernel debugger to the kernel, which will make it obvious that someone is debugging!)
asveikau 5y ago
LoadLibrary is not guaranteed to have the same address across processes. As of Win7 you might also have a process link to kernelbase and not kernel32, so it's not even guaranteed to be in the same DLL. However it should be possible to use GetModuleHandleEx to find the DLL base addresss in a remote process, then ReadProcessMemory to implement your own remote GetProcAddress.
- NtGuy25 5y ago
  You do end with modules having the same address in every process if untampered though. This is due to Copy on Write windows implements internally with DLL's to save space. So while not guaranteed. On X64 you can be certain that because of COW the module will have the same address.
  - asveikau 5y ago
    That's not true. You're not considering different virtual addresses backed by the same pages. Yes, the loader will create file-backed memory mappings and not redundantly store read-only parts. However, it is free to load it at a different address in each process. This can happen via ASLR, or if the mapping is already claimed by the time the module loads. They may get the same base address repeatedly in multiple processes and work most of the time, but it's not guaranteed.
    - barchar 5y ago
      It's extremely likely for stuff from Kernel32.dll. > That's not true. You're not considering different virtual addresses backed by the same pages. technically I suppose, but PEs don't tend to be relocatable, so if it mapped it in at different virtual addresses that would be extremely unlikely to be backed by the same pages as much of the just-mapped-in code would need relocs

codedokode 5y ago

Isn't this a way to introduce bugs? For example: - injected DLL can change some process-related settings and break main program - injected DLL can call non-reenterable function from a system library simultaneously with main program

bmm6o 5y ago
No need to go that far. If you allow an untrusted process to write to your memory, you've already lost. One thing I haven't seen called out yet is that there is security associated with this API call - ordinary users can only call this on processes that they own. (And as far as the terminology, these aren't "bugs" since they aren't defects in the software.)
barchar 5y ago
I mean sure. If you can do this you can debug the process (how do you think debuggers are implemented?) and ofc once you're debugging a process you can introduce bugs and cause random havoc. Linux can do this too with ptrace. And mac has something similar I'm sure, you gotta be able to debug. Now, the target process can implement countermeasures against you, that's what anti-debug is, but it's impossible in the general case to defend yourself against a debugger with the same privilege level as you. (it is an arms race though, so sometimes it's easiest to resort to kernel-mode anti-anti-debug techniques even against pure user-mode anti-debug. If you do that you need to disable KPP, and you can't disable KPP in the supported way because the supported way is to attach a kernel debugger to the kernel, which will make it obvious that someone is debugging!)

asveikau 5y ago

LoadLibrary is not guaranteed to have the same address across processes. As of Win7 you might also have a process link to kernelbase and not kernel32, so it's not even guaranteed to be in the same DLL. However it should be possible to use GetModuleHandleEx to find the DLL base addresss in a remote process, then ReadProcessMemory to implement your own remote GetProcAddress.

NtGuy25 5y ago
You do end with modules having the same address in every process if untampered though. This is due to Copy on Write windows implements internally with DLL's to save space. So while not guaranteed. On X64 you can be certain that because of COW the module will have the same address.
- asveikau 5y ago
  That's not true. You're not considering different virtual addresses backed by the same pages. Yes, the loader will create file-backed memory mappings and not redundantly store read-only parts. However, it is free to load it at a different address in each process. This can happen via ASLR, or if the mapping is already claimed by the time the module loads. They may get the same base address repeatedly in multiple processes and work most of the time, but it's not guaranteed.
  - barchar 5y ago
    It's extremely likely for stuff from Kernel32.dll. > That's not true. You're not considering different virtual addresses backed by the same pages. technically I suppose, but PEs don't tend to be relocatable, so if it mapped it in at different virtual addresses that would be extremely unlikely to be backed by the same pages as much of the just-mapped-in code would need relocs