Hacker News Reader

Comment by rwmj | Hacker News Reader

I think the even crazier thing is Windows having a function to allocate memory in another process (https://docs.microsoft.com/en-us/windows/win32/api/memoryapi...). That seems like a potential source for all kinds of impossible to track bugs.

> The customer is a major anti-virus software vendor! The customer has important functionality in their product that that they have built based on this technique of remote code injection, and they cannot afford to give it up at this point.

Oh now it makes sense.

View on HN

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`!

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

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

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!)

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.

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.

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.

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

Code injection is common in video gaming, it is used by the Steam overlay, OBS Studio, anticheats, profilers, ...

You can allocate memory in another process on Unix too: use ptrace to make the other process call malloc (use PTRACE_SETREGS to set PC to malloc and the first argument register to the number of bytes, then intercept the return).

GDB will use this if you tell it something like `p foo("bar")`, as it needs to allocate memory for that string somewhere.

What would be the use case of AV software needing to perform remote code injection?

There's barely a case for AV software existing at all. It's the root cause for all kinds of impossible to track bugs and performance regressions.

The best kind of antivirus is the one that stays quiet unless you specifically ask it to scan a file. Did someone say Clam AV just now?

Why did you download an executable that you don't trust? Don't even scan it, just delete it and go find one you do trust.

Trust, but verify.

Cries in Symantec Endpoint Protection with "file access scans" turned on, compiling a fairly average .NET solution

Reply on news.ycombinator.com