Nypyren: One thing you left out is that most code is not compiled to be relocatable, which means moving it to another address won't work unless you fix up every absolute address in the code (which, for processes you don't have the source for, is in the form of binary machine code).
As far as getting all the memory used by a program, the PSAPI function QueryWorkingSet does exactly that, but like I said, that is the easy part.
CreateRemoteThread
If your solution becomes too complex (AND HOW), think about the problem in a different way.
Make a tool where you can designate all of the "Good" processes on your system, and a button "KILL THE INSURGENTS!!" that simply enumerates all processes and forcibly kills everything that's not in your "Good" list.
This will be FAR easier and actually doable in a weekend rather than a year or so of R&D to figure out how to turn processes into a clown-car.
Make a tool where you can designate all of the "Good" processes on your system, and a button "KILL THE INSURGENTS!!" that simply enumerates all processes and forcibly kills everything that's not in your "Good" list.
This will be FAR easier and actually doable in a weekend rather than a year or so of R&D to figure out how to turn processes into a clown-car.
Extrarius: Relocating absolute addresses is a serious pain, but it's even more of a pain when you take heap data into account as well. Not only do you have to disassemble the entire program, you have to trust that it doesn't do anything out of the ordinary with its memory manager or stack layout. With data, you have no defined alignment for where a pointer may be in a struct. In code, you're guaranteed that all instructions are readable in the same manner. I just left that implied and meant that analyzing data would be harder if you had to do it. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
