Another great explanation, and very educational about 'how' EP works. Your 'what is a virus' discussion reminds me of what someone said in response to 'what is a weed' ... a weed is anything you don't want growning in your garden ...
EP is my first foray into 'shell extensions' (if that is the correct term), necessitated by Win 11's brain-dead approach to the taskbar and start menu. Before this, I've always been determined to try to stay mainstream. So I'm curious - does EP's approach match that taken by the likes of 'Start Is Back', and similar programs, or do they take a radically different approach? I was attracted to EP because of it's light weight and lack of 'fluff'.
Yeah, personally, I try to keep up with the upstream as much as possible. It is very difficult to maintain patches, especially as time moves on and the code base radically diverges from what your patches expect. To be completely honest, I will probably switch to using the new taskbar once they implement labels on it 2/3 years from now on and that'd be it. To me, as well, the changes in Windows 11 are too drastic and don't actually make much sense (I prefer what the Windows 10 shell matured into, it was familiar and functional), but I wanted/want to use the newer kernel and the new system capabilities (WSL2 disk mounting, WSL2 GPU support, Android apps, better support for 12th gen CPUs etc). Truth is, Windows 11 is the way forward for new system builds, so hopefully EP is a stop gap band aid until thing go back on track and they reimplement the missing features.
Before I worked on EP, I had way less knowledge in how COM (Component Object Model), the backbone of program interactions under Windows works, and how a lot of the stuff actually worked internally. The way the loader works is generalistic, I supposed Windows had something similar to what is described in the literature a loader is doing (on GNU/Linux, the loader behaves largely the same when it comes to loading libraries dynamically, for example, and so on), so I built the initial pieces of the software around my initial knowledge. Further on, as I explored more, I found alternative approaches and learnt how other software does it etc. Since you asked, StartAllBack gets loaded by overriding component registration for some of the components loaded by explorer.exe. It registers its DLLs as providing the requested components, and then itself forwards the calls to the original implementations, in the middle hooking itself into explorer.exe. It definitely is an approach as well; injection happens a bit later in explorer.exe's lifetime, but for the program's purposes, it is enough for it to work. Can Microsoft brake that as well? Sure, they could guard certain GUIDs against being overridden via the registry and hardcoding the path to the implementation requested in the COM loader/registry itself. Will they do it? Again, idk, probably not. Anyway, a different, interesting approach as well, but I learnt about it way after I started doing the groundwork for EP; nevertheless, I am glad I learnt about it - projects like these teach you a lot, indeed, if you're open to it.
So yeah, nothing fundamentally different. It all comes down to getting injected into processes. I guess the ultimate tool to guard against most user land protections would be to write a driver that hooks process creation, for example, and injects from there at the right time (blocking, reliable, in-time process creation notifications are not available via a system API to user land processes, on Windows; there is an API through in the kernel). That would be pretty rock solid. The problem with that is how do you distribute that to other people. For all intents and purposes, for general consumers, the kernel land is jailed on Windows - drivers (programs that run in the kernel) have to be signed, and driver signing is expensive and subject to obeying a set of rules which might have something against what this potential driver might do. Not to mention, but this is of less concern, since eventually one would reach a stable version, by iterating and fixing bugs, but doing stuff in the kernel is more sensitive - at the slightest mistake, the OS crashes itself because it cannot guarantee the state it got into; the famous BSOD is an induced crash, that's very important to keep in mind. BSODs are a form of protection against situations where the machine CPU got into a state where it cannot guarantee the intergity of the memory/registers etc. In the user space, this intergity is maintained by isolating application into processes, virtualizing the memory, flushing register contents when switching tasks etc. In the kernel space, since all code runs in the same memory space, even though the OS can recover from most software bugs, as a precautionary measure against potential data corruption/undefined state it might get into, the OS usually stops when it reaches such a condition, BSODs, and restarts. But, as I said, writing a driver is not impossible and can be a solution - I'd be more concerned with how effective I could distribute such a driver to end users; that I'd think would be the real problem.
