How can both the IPC client and IPC server call the shared remoting interface (the class inheriting MarshalByRefObject) to communicate, without having to put the interface class inside in the injecting application? For example, if I put the interface class in the injected library project that gets injected into my target process, my injecting application cannot reference that interface.
Edit: I have answered the question below.
As of EasyHook Commit 66751 (tied to EasyHook 2.7 alpha), it doesn’t seem possible to get the instance of the remoting interface in both the client (that process that initiated injection of your DLL) and the server (the injected process running your injected DLL).
What do I mean?
Well, in the FileMon and ProcessMonitor examples, notice how the shared remoting interfaces (
FileMonInterface, embedded inProgram.cs, for Filemon, and DemoInterface, in its own file, for ProcessMonitor) are placed in the injecting assembly.FileMonInterfaceis in the FileMon project.DemoInterfaceis in the ProcessMonitor project.Why not the other round? Why not put
FileMonInterfacein the project FileMonInject, and putDemoInterfacein ProcMonInject? Because then the interfaces will no longer be accessible to the calling applications (FileMon and ProcessMonitor).The reason is because EasyHook internally uses:
This remoting call allows clients to call your (server) interface, but the server itself (you, the application) cannot call it.
The Solution
Instead, use:
What I did was add an overload to EasyHook’s RemoteHook.IpcCreateServer() to accept my new “way” of doing .NET remoting.
It’s ugly, but it works:
The Code
Replace the entire IpcCreateServer method (from brace to brace) with the following code. There are two methods shown here. One is the more detailed overload. The second is the “original” method calling our overload.
That’s it. That’s all you need to change. You don’t have to change IpcCreateClient().
Using the Code
Here’s how you would use the new overloaded method:
Say you have
as your shared remoting interface.
Create a new instance of it, and store its reference. You’ll be using this to communicate with your client.
Here’s how you would have created that remoting channel before:
Here’s how you would create that remoting channel now:
Don’t forget to…
I got this solution from this StackOverflow post. Please be sure to do as he says and override InitializeLifetimeService to return null:
I think this is supposed to keep the client from losing the remoting interface.
Uses
Now, instead of being forced to place your remoting interface file in the same directory as your injecting project, you can create a library specifically for your interface file.
This solution may have been common knowledge to those having had experience with .NET remoting, but I know nothing about it (might have used the word interface wrong in this post).