Implementing Global Injection and Hooking in Windows

Didn't Microsoft do this in the old pre-Chromium Edge? It probably would've caused more of an outcry from users if anyone actually used the old Edge as their primary browser. Personally, I feel like this is the "wrong way" to enhance browser security. Should the browser, as important as it is, behave fundamentally differently than all other processes within an OS? What about other VIPs (Very Important Programs)? Who's to decide which apps are important enough? The right way, to me, would be for the Chrome/Chromium team (along with other browser vendors) to lobby and/or work with OS vendors such as MS, Apple, Canonical, etc. to come up with sensible OS mechanisms to limit dynamic code, with appropriate user control and override options. Sure, that's a bigger undertaking and "some users will be confused" as always. But it's not worth it to me to keep shrinking what part of my personal computer I can actually control just to gain a little bit more security and stability. I want to be the one to make the choices and strike a balance that's personally right for me. So for that reason, I hope this is one feature flag you will never enable by default.

I'm curious if you could attempt to "fend off" such hooks into your address space?

Even not being Microsoft, our hooking engines are also extremely robust and has additional features (higher level interface to hook in any language and hooking COMs and .NET): https://github.com/nektra/Deviare2 https://github.com/nektra/Deviare-InProc, and https://github.com/nektra/RemoteBridge

They are being used in well known security companies and intelligence organizations.

Lost? Past? The Windows world still runs on this stuff, and there are still plenty of people who know how it works and make money from knowing.

That said, MS have unintentionally (I think) done a pretty good job of scrubbing the internet clean of useful information about it by breaking all their links multiple times. I keep a personal copy of some things, such as Matt Pietrek's classic two-parter "An In-Depth Look into the Win32 Portable Executable File Format", lest they disappear completely while the technologies they describe continue to run the world.

Edit: MS only appear to have part 2 of that article in their archive, and it contains broken links (of course). Both parts can still be read at [1] and [2] and remain as relevant as they were the day they were written

[1] https://bytepointer.com/resources/pietrek_in_depth_look_into...

[2] https://bytepointer.com/resources/pietrek_in_depth_look_into...

You will need to disable SIP (and library validation) to do this, because your code signature will not match the target process's, which is kind of what this is intended to prevent. This is also why you cannot attach a debugger to arbitrary processes when those protections are engaged. But once you turn that off, there's a lot you can do, here's one of my projects that might give you an idea of one way to do this: https://gist.github.com/a70d44951cb72f82efee3317d80ac07f

This is within process access limits.

Non elevated process can't inject into elevated process. X user process can't inject into Y user process.

If user has access to process, they have very well access to modify by decompiling or reverse engineering it. Dynamic injection makes it much more seamless and less painful.

Much of this is borne out of not having source for code critical to your business. So, you inject patches.

You can ptrace() on Linux as well, it just isn't as easy: https://blog.xpnsec.com/linux-process-injection-aka-injectin...

I don't have a question, but I wanted to let you know that you can enumerate processes and threads via NtQuerySystemInformation instead of CreateToolhelp32Snapshot, and it's much faster. The latter is slow only due to weird file section mapping behavior and not due to the actual query.