Is it possible to use hooks to jump to another process' running memory, and then jump back, without anything like a DLL injection?
For instance, if process A has a procedure foo and process B has a procedure bar with an identical prototype to foo (used for a hook), is it possible to hook foo to jmp to bar, assuming both processes are running?
EDIT: This needs to be done on Windows.
A process by definition is a sandbox. If you even by mistake step outside your address space it's raised and caught as a SIG_USR signal and reported as a segmentation fault
Having said that there are inter process communication mechanisms such as shared memory -shmem, Pipes and sockets that you can use to communicate across processes.
Edit :
There are RPC ( remote procedure calls) mechanisms available as well Such as CORBA That provide remote method invocation.
Each process in Windows (as well as in Unix and probably vast majority of other modern OS) has it's own virtual memory space, which usually maps to different physical addresses. Consequently injecting a DLL into the address space of another process is the only method to hook anything in that process. On the other hand once you have a DLL in that process, there are plenty of things you can do there, eg. spawn your own thread and communicate with the parent process using Windows messages (as one of the easiest communication methods in Windows).
Related
I know the answer to "why is it this way" is because the language was invented so, but it seems like a lot of wasted effort that fork() spawns a copy of the process that called it. Perhaps it is useful sometimes, but surely the majority of time someone wants to start a new process its not to be a duplicate of the calling one? Why does fork create an identical process and not an empty one or one defined by passing an argument?
From yolinux
The fork() system call will spawn a new child process which is an
identical process to the parent except that has a new system process
ID
In other words when is it useful to start with a copy of the parent process?
One big advantage of having the parent process duplicated in the child is that it allows the parent program to make customizations to the child process' environment before executing it. For example, the parent might want to read the child process' stdout, in which case it needs to set up the pipes in order to allow it to read that before execing the new program.
It's also not as bad as it sounds, efficiency wise. The whole thing is implemented on Linux using copy-on-write semantics for the process' memory (except in the special cases noted in the man page):
Under Linux (and in most unices since version 7, parent of all unices alive now), fork() is implemented using copy-on-write pages, so the only
penalty that it incurs is the time and memory required to duplicate the
parent's page tables (which can be also copy-on-write), and to create a unique task structure for the child.
There are some very legitimate uses of the fork system call. Here are a few examples:
Memory saving. Because fork on any modern UNIX/Linux system shares memory between the child and parent (via copy-on-write semantics), a parent process can load some static data which can be instantly shared to a child process. The zygote process on Android does this: it preloads the Java (Dalvik) runtime and many classes, then simply forks to create new application processes on demand (which inherit a copy of the parent's runtime and loaded classes).
Time saving. A process can perform some expensive initialization procedure (such as Apache loading configuration files and modules), then fork off workers to perform tasks which use the preloaded initialization data.
Arbitrary process customization. On systems that have direct process creation methods (e.g. Windows with CreateProcess, QNX with spawn, etc., these direct process creation APIs tend to be very complex since every possible customization of the process has to be specified in the function call itself. By contrast, with fork/exec, a process can just fork, perform customizations via standard system calls (close, signal, dup, etc.) and then exec when it's ready. fork/exec is consequently one of the simplest process creation APIs in existence, yet simultaneously one of the most powerful and flexible.
To be fair, fork also has its fair share of problems. For example, it doesn't play nice with multithreaded programs: only one thread is created in the new process, and locks are not correctly closed (leading to the necessity of atfork handlers to reset lock states across a fork).
Contrary to all expectations, it's mainly fork that makes process creation so incredibly fast on Unices.
AFAIK, on Linux, the actual process memory is not copied upon fork, the child starts with the same virtual memory mapping as the parent, and pages are copied only where and when the child makes changes. The majority of pages are read-only code anyway, so they are never copied. This is called copy-on-write.
Use cases where copying the parent process is useful:
Shells
When you say cat foo >bar, the shell forks, and in the child process (still the shell) prepares the redirection, and then execs cat foo. The executed program runs under the same PID as the child shell and inherits all open file descriptors. You would not believe how easy it is to write a basic Unix shell.
Daemons (services)
Daemons run in the background. Many of them fork after some initial preparation, the parent exits, and the child detaches from the terminal and remains running in the background.
Network servers
Many networking daemons have to handle multiple connections at the same time. Example sshd. The main daemon runs as root and listens for new connections on port 22. When a new connection comes in it forks a child. The child just keeps the new socket representing that connection, authenticates the user, drops privileges and so on.
Etc
Why fork()? It had nothing to do with C. C was itself only coming into existence at the time. It's because of the way the original UNIX memory page and process management worked, it was trivial to cause a process to be paged out, and then paged back in at a different location, without unloading the first copy of the process.
In The Evolution of the Unix Time-sharing System (http://cm.bell-labs.com/cm/cs/who/dmr/hist.html), Dennis Ritchie says "In fact, the PDP-7's fork call required precisely 27 lines of assembly code." See the link for more.
Threads are evil. With threads, you essentially have a number of processes all with access to the same memory space, which can dance all over each others' values. There's no memory protection at all. See The Art of Unix Programming, Chapter 7 (http://www.faqs.org/docs/artu/ch07s03.html#id2923889) for a fuller explanation.
Is it possible for a DLL and an executable to communicate from a different process?
For an example:
Child.dll is loaded into Target.exe...
Owner.exe is running...
Owner.exe sent message "close" to Child.dll
Child.dll received message "close" from Owner.exe
Child.dll executed: ExitProcess( 0 );
Target.exe has exited, therefore Child.dll has already been unloaded.
So, is it possible? If so, how? Thanks.
A DLL does not run in a separate process, it runs in the process space of the process which invokes some methods or accesses data contained within the DLL.
So if no processes are present using a DLL, the operating system may decide to swap the pages of memory mapped for the DLL to the SWAP space or even unload the DLL entirely from the memory.
It's possible through "inter process communication". Note that with IPC, you don't send a message to the DLL, you send it to the other process. So if process A wants to tell process B a message, it does so (using whatever means they've established for communication, like sockets, shared memory, named pipes, etc.). It's possible for the IPC code to live in a DLL.
Note that you can't talk to a DLL by itself, like you've outlined in your question. You have to talk to the process (but again, the code that handles the communication for the process may live in a different DLL).
One reason for this is that multiple processes can be using the same DLL at the same time. If you've got two processes running, both of them using Child.dll, and you want to send a message to Child.dll a message, which process should get that message? It doesn't quite make sense, seeing as the two processes are entirely independent of each other, even if they're both using the same DLL. Hence, you can't talk to a DLL by itself; rather, you talk to a process.
I have some doubts about anti dll injection in C++.
I have a game C++ based, Im having problems with hackers with dll injection.
Then i need to prevent it.
I find notify hook there from there:
MSDN - Notification Hooks
But i dont have idea how to use it.
Its is possible notify hook to prevent dll injection?
How its possible? (With and example better).
Can be from dll? (With example better).
Thanks for read that post.
PS: sorry for my english.
Forget it, unless you do very sophisticated things, it's not going to work. By sophisticated I mean something like the code obfuscation, anti-debugging technology used in Skype. Just look at this talk.
You can spend a ton of time on trying to prevent DLL injection, in the end somebody will spend less time than you and circumvent your protection. I think the time would be better invested in an architecture that's more secure and tamperproof (ie calculating scores on the server, etc).
It's a cat and mouse game you can't win.
This question is old but I will briefly answer it in better form for anyone who does happen to stumble upon it magically after a proper response.
You cannot fully prevent code injection from within your own process, but you can try to do some tricks without interception of other processes. It is not recommended because you need to have experience and knowledge with lower-level tasks, especially to get it working properly and not prevent functionality of your own software, however...
Asynchronous Procedure Calls (APC) is an implementation from the Windows Kernel. It is primarily used for code injection into other running processes, Windows uses it a lot itself for a variety of things such as notifications being sent to specific processes. When a user-mode process calls QueueUserApc (KERNEL32), NtQueueApcThread (NTDLL) will be invoked. NtQueueApcThread (NTDLL) will perform a system call which will cause NtQueueApcThread (NTOSKRNL) to be invoked, which is not exported by NTOSKRNL - for anyone wondering, NTOSKRNL is the Windows Kernel, and a system-call is nothing more than a transition from user-mode to kernel-mode since the Native API System Routines exist in kernel-mode memory, NTDLL routines for NTAPI are system call stubs which direct control up to the Windows Kernel. When NtQueueApcThread (NTOSKRNL) is called, it'll use KeInitializeApc and KeInsertQueueApc (both do happen to be exported by NTOSKNL). When the APC is actually issued to the targeted process, KiUserApcDispatcher (NTDLL) will be locally called within the process, unless the APC is performed in a more extensive manner to bypass this activity (99% of the time it will not be prevented). This means that you have an oppertunity to intercept this behavior and prevent APC injection into your own process with one single local hook in your own process, via byte-patching (also known as "inline hooking") KiUserApcDispatcher, exported by NTDLL. The only problem which you will face is that it is undocumented and this is not officially supported by Microsoft; you'll need to figure out how the parameters work and how to prevent the callback routine from blocking off genuine requests which are needed to provide functionality for your own software. This will however include prevention of kernel-mode APC injection, not just user-mode attacks.
There are many ways to inject code into a process, and APC is simply one of them. Another common method would be through remote thread creation. When a user-mode process attacks another process via remote thread creation, it'll typically call CreateRemoteThread (KERNEL32). This will lead down to RtlCreateUserThread (NTDLL), and RtlCreateUserThread will call NtCreateThreadEx (NTDLL). NTDLL will perform a system call and then NtCreateThreadEx (non-exported routine from the Windows Kernel) will be invoked in kernel-mode memory. In the end, the targeted process will have LdrInitializeThunk locally invoked, and RtlUserThreadStart will also be invoked locally. Both of these routines are exported by NTDLL. This is a same scenario as with APC... You can patch LdrInitializeThunk locally, however you must do it properly to prevent genuine functionality within your own software.
These two techniques are not full-proof, there is no "full-proof" solution. There are many ways to inject code into a process, and there are very sophisticated methods to bypass said solutions from myself. Anti-Virus software has been battling anti-RCE/self-protection for as long as I can remember, as has Anti-Cheat systems. You should look into kernel-mode device driver development as well, it'll allow you to register kernel-mode callbacks which can help you out.
The first callback you should look into is ObRegisterCallbacks. It allows you to receive a Pre-operation callback notification whenever NtOpenProcess is called from the Windows Kernel. This means that user-mode processes will also trigger it, since NtOpenProcess ends up being called in kernel-mode after NTDLL makes the system-call. I cannot remember specifically if the callback APIs are triggered in the NtOpenProcess stub itself or if it goes deeper into Ob* kernel-mode only routines, but you can check at ease with WinDbg with remote kernel debugging, or Interactive Disassembler (target ntoskrnl.exe and use the symbolic links provided by Microsoft). ObRegisterCallbacks supports notifications for both handle creation & duplication for the process and the processes' threads, you can strip access rights you don't want permitted for the requested handle.
The second callback you should look into would be PsSetCreateThreadNotifyRoutineEx. This callback routine will allow you to receive a notification whenever a new thread creation occurs on the system; you can filter it out for your own process and if a rogue thread is created, terminate the thread.
The third callback you should look into would be PsSetLoadImageNotifyRoutineEx. This callback will provide a notification whenever a new module is loaded into a process; once again, you can filter for your own process. If you detect a rogue module, you can attempt to have your process call LdrUnloadDll (NTDLL) targeting the base address of the newly loaded image, however the reference count for the module needs to be 0 for it to be unloaded. In that case, you can try "hacky" methods like calling NtUnmapViewOfSection/NtFreeVirtualMemory. Bear in mind, if you mess up the rogue loaded module and it has set memory byte patches to redirect execution flow to its own routines, unless you restore them, your process will crash when they are referenced.
These are some ideas, commonly the ones typically used. Kernel-Mode callbacks are very popular among security software and anti-cheat software. As for thread creation, you'll be interested in mitigating this as much as possible -> if you only look for rogue DLL loads then you'll miss out on reflective DLL loading. Also remember of the other code injection methods, like thread hijacking, shared window memory exploitation with ROP chain call exploitation, DLL patching on-disk, etc.
I am developing an application based on one library.
I am facing problem related to communication in between Parent Process and Forked Process from Parent process.
I need to access Function in the library, and pointer for library is in Parent process and i am calling functins of library from Forked process using pointer in Parent Process. Function in Parent process get called from Forked process but currusponding function in Library stays in bloked state as it should be called from Parent Process only not from Forked process.
What should be the solution for this problem.
***Update:
Library which i mentioned is not exatly loaded library it has one class and i have instantiated that class through my Parent Process and then the library will create its own threds and keep running in it,
So when i do call to library through Parent Process it goes through and when i call Library functions using the Parent Pointer through Forked Process it does not do through. It does not segements but it gets bloked in the function call.
After the fork, both your processes have the library loaded and any existing pointers are valid in both of them, but there's no further connection between them in terms of function calls or access to data. If the parent calls a function, the parent will run the function. If the child calls a function, the child will run the function. There's no notion of one process calling a function in another process.
If you want your two processes to communicate, you need to write code to make them do so. Read about interprocess communication to learn about the various ways to do that. One simple option is to call pipe() prior to forking, and after the fork, have the parent close one of the file descriptors and the child close the other. Now you have a way for one process to send messages to the other. Do that twice and you have two-way communication. You can make the parent run a loop that waits for messages from the child via one pipe, acts upon them, and sends back the results via the other pipe.
You don't say what OS you are using, but generally pointers are not valid across processes. Most OSes give each process its own virtual memory space, so address 0x12345678 may be a pointer to something in one process, but not even an available valid address in another.
If the forked process wants to call a function, it will have to gain access to it itself (link or open the library itself, etc.)
If you're trying to share memory across two processes, but the same executable, then you should be using threads instead of forking a separate process. As others have mentioned, forking gives you a separate memory space, so you can't pass a pointer. With threads, you'd share the same memory space.
You have reached the Inter Process Communication (IPC) problem, where one program wants to make another one do something.
Since you fork()ed your child process, it now lives on his own, and to be able to execute a function on the parent process you'll have to figure out a way for them to communicate:
Child : Dad, please execute this function with these arguments, and give me the result in this pointer, please.
The problem is very widely known, you have many solutions, one of which is to design your own IPC language and implement a Remote Procedure Call (RPC) over it.
Now, people have solved the problem before, so you can take a look at some of these things:
IPC Methods
pipes
sockets (unix and network)
message queues
shared memory
RPC protocols
D-Bus
Corba
TPL (not an RPC protocol, but you can build one with it)
I have a very simple interface which needs to communicate between processes. It's currently implemented in a very simple manner (all single proc):
bool GetFoo(struct Foo *outFoo);
bool GetBar(struct Bar *getBar);
Such as:
Foo foo;
if (!GetFoo(&foo))
{
ReportError();
}
GetFoo fills out the "Foo" data structure with pure data (that is, no pointers - it's purely blitable data).
I need to convert this in-process function call to be between two processes on the same machine (in this case it's always the same machine). Is there a commonly followed idiom for cross-process calls in C++ on Windows? Is there some kind of intra-process communication supported by Windows? Should I be using shared memory instead?
One note: I don't want to take a dependency on anything other than the Windows APIs if at all possible.
You have many choices, but in my personal experience the most popular/easy to use ones are: sockets & pipes.
See here for all IPC options available for Windows.
I'm not sure what the most common is -- to truly answer that we'd have to have some kind of polling. That said, the most flexible way would probably be to expose the methods via DCOM.
A common method would be RPC, it can be implemented in various ways for instance as Billy mentioned using COM` (or DCOM if the processes are residing on different machines).
Although you may want to think about not doing direct RPC calls and instead have a named pipe between your processes which is used for the communication.
There are a number of ways to communicate between processes on the same computer in Windows. Which one works best depends on the relationship between the two processes. Is one process expected to start the other? In that case an out-of-process COM server would probably work best, since you can restart the other process if it is not already running.
If performance is critical, then shared memory will give you the most control the speed of passing the data between your processes.
One thing to think about is the failure semantics of running multiple processes. What does the calling process do if the callee is not there?