Sign in to follow this  

CreateRemoteThread

This topic is 4339 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I haven't personally written an example, but you should be able to do what you need with the following functions:


VirtualAllocEx // used to allocate memory in another process
WriteProcessMemory // used to copy your function to the other process
VirtualProtectEx // used to allow code execution in your new memory
CreateRemoteThread // 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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
(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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites

This topic is 4339 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this