CreateRemoteThread
Author
Does anyone have a really basic CreateRemoteThread example i could use? I have searched for tutorials for a while but only find really advanced tutorials when all i need is a simple one that only has remote thread functions without the dll injections.
You pretty much need to inject a DLL to properly use CreateRemoteThread, because the code needs to be available to the remote process. You can either inject a dll or allocate memory in the other process and write your code to it, and injecting a dll is far easier.
I haven't personally written an example, but you should be able to do what you need with the following functions:
Actually enumerating processes and obtaining process handles for process IDs is very simple and info is easy to find using Google.
VirtualAllocEx // used to allocate memory in another processWriteProcessMemory // used to copy your function to the other processVirtualProtectEx // used to allow code execution in your new memoryCreateRemoteThread // you know what this does.Actually enumerating processes and obtaining process handles for process IDs is very simple and info is easy to find using Google.
Author
Alright, that gives me a little bit more knowledge. So in order to use createremotethread you have to have a handle to the process. Since i don't know the process handle i inject a dll into the kernal.dll or the process directly? The dll i inject contains the handle that i will attempt to connect to using the createremotethread.
I just put that together from what I previously read(but didn't understand) and what you just told me. Am i correct when i say the above statement?
I just put that together from what I previously read(but didn't understand) and what you just told me. Am i correct when i say the above statement?
Nope, not at all. You must get the process handle using OpenProcess, because injecting a dll (to a single process, in the standard way) requires using CreateRemoteThread.
Why do you need to use CreateRemoteThread?
Why do you need to use CreateRemoteThread?
Author
2 reasons, expanding my knowledge and cleaning up my process list. I have another computer that i open task manager every 30 minutes to end tasks that slow the computer down any and instead of scimming through the 50 processes I want to bind them all into one process(explorer.exe most likely). Then any program that appears on the process list besides explorer.exe i can simply end it's task without searching. I know this stuff i'm asking for won't allow me to bind compiled windows programs like svchost.exe and all the other defaults, I figure this is where I would have to start though. It's not for malicious purposes, I know this would be used for it probably more than not.
To find the process(es) you might want, look at the function "EnumProcesses" and its related links.
Each process contains "modules". Modules are either the contents of the .EXE or the .DLLs that the process has loaded (which will include any injected DLL if you decide to do that).
The DLL injection method is easier if you want to do anything useful in your thread. If you use the VirtualAllocEx/CreateRemoteThread method, all function addresses that your local function might have been calling can (and usually will) be totally different on the other process. You cannot use optimized switch statements without doing address translation on the jump table.
The VirtualAllocEx method is "cleaner" because you don't inject a new module into the other process, but you have all the headaches of "flying blind" and having to manually do everything that the operating system's module loader does.
Each process contains "modules". Modules are either the contents of the .EXE or the .DLLs that the process has loaded (which will include any injected DLL if you decide to do that).
The DLL injection method is easier if you want to do anything useful in your thread. If you use the VirtualAllocEx/CreateRemoteThread method, all function addresses that your local function might have been calling can (and usually will) be totally different on the other process. You cannot use optimized switch statements without doing address translation on the jump table.
The VirtualAllocEx method is "cleaner" because you don't inject a new module into the other process, but you have all the headaches of "flying blind" and having to manually do everything that the operating system's module loader does.
(Reply to your most recent post)
Why don't you write a Windows Service? Those all load inside of "svchost.exe" so your process list is nice and clean. Plus, you can start and stop them using the services user interface. If you don't actually need to access code or data inside another process and you're just trying to avoid having 50 tasks running in the task list, this is the best option.
Why don't you write a Windows Service? Those all load inside of "svchost.exe" so your process list is nice and clean. Plus, you can start and stop them using the services user interface. If you don't actually need to access code or data inside another process and you're just trying to avoid having 50 tasks running in the task list, this is the best option.
I don't think what you apparently want to do (move arbitrary processes you from their own process space to inside another process) is possible without writing kernel-level code. If you can't figure out CreateRemoteThread, you will probably not be able to write kernel-level code even with our help. If you're still interested, you might have some luck in the newsgroups "microsoft.public.development.device.drivers", "microsoft.public.win32.programmer.kernel", or "comp.os.ms-windows.programmer.nt.kernel-mode" (in descending population order, and thus likely helpfulness)
Note that even with kernel-mode code, you won't be actually moving the processes around (because that would require disassembling the code, adjusting addresses, and reassembling it so it could work at a different base address), but instead just preventing certain processes from being listed.
If you only want to hide them task manager and don't care how it's done, you could intercept the API call it uses to get the process list or write a program that finds the task manager window and just removes certain entries from the box where it lists processes.
Note that even with kernel-mode code, you won't be actually moving the processes around (because that would require disassembling the code, adjusting addresses, and reassembling it so it could work at a different base address), but instead just preventing certain processes from being listed.
If you only want to hide them task manager and don't care how it's done, you could intercept the API call it uses to get the process list or write a program that finds the task manager window and just removes certain entries from the box where it lists processes.
O__o
Moving an existing RUNNING process into another process?
That's not a very good idea...
You can do almost absurd things to running processes if you DebugActiveProcess on them. You can SuspendThread, GetThreadContext, Copy all modules and memory regions (including stack and data), remap the import table for each module, CreateRemoteThread(suspended), SetThreadContext, ResumeThread. And this is about as far as you can theoretically get.
Unfortunately, you can't be sure that you get all of the data that the process was dealing with. I've looked at the active memory regions of a typical process, and it's a *$%^&#ing RATS NEST. You will be hard pressed to figure out a reliable way of doing this.
Not to mention that I've seen an app that's almost filled up its entire 4GB virtual address space. If you tried to squish 50 large processes into one like this, you'd have to use a 64-bit operating environment just to fit it all.
Moving an existing RUNNING process into another process?
That's not a very good idea...
You can do almost absurd things to running processes if you DebugActiveProcess on them. You can SuspendThread, GetThreadContext, Copy all modules and memory regions (including stack and data), remap the import table for each module, CreateRemoteThread(suspended), SetThreadContext, ResumeThread. And this is about as far as you can theoretically get.
Unfortunately, you can't be sure that you get all of the data that the process was dealing with. I've looked at the active memory regions of a typical process, and it's a *$%^&#ing RATS NEST. You will be hard pressed to figure out a reliable way of doing this.
Not to mention that I've seen an app that's almost filled up its entire 4GB virtual address space. If you tried to squish 50 large processes into one like this, you'd have to use a 64-bit operating environment just to fit it all.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
