I was just wondering if this was possible before I start working on it. I can inject and run C#开发者_C百科 code into a running process, as well as enumerate all the loaded .NET modules. Separately, I can edit a .NET DLL's instructions to add my method calls. Obviously I can't edit the DLL while the DLL is loaded, but when I try it, the system message tells me I can't edit it because it's loaded in another process. This has led me to believe that if I am in the same process (because of, say, my injecting code), I can edit the loaded DLL. I suspect this isn't right.

If not, do you think it might be possible to unload the target DLL, edit it, and reload the target DLL? Will the system remap all its values correctly (since the new DLL would be larger by a few instructions)? I have a feeling that if it's possible to unload the DLL, edit it, and reload it into the process, the OS should take care of the rest.

Thank you for any insight and feedback.

yes this is possible.

"Replace any .NET method with your own delegate! "

See: http://research.microsoft.com/en-us/projects/moles/

here's the video: http://channel9.msdn.com/blogs/peli/moles-replace-any-net-method-with-a-delegate

This is in the "Code Injection" category. Pretty interesting stuff.

Is this technically overwritting the MSIL? Not sure. However, this technique will give you the same end result. That's what we care about right?

Once a .Net DLL is loaded into a process by the CLR the only way to remove it is to unload all AppDomain instances which are using the DLL. So I guess it would be possible to edit a loaded DLL by doing the following

1. Unload all AppDomain instances containing the DLL thus removing an holds on the DLL
2. Edit the DLL on disk or just put the altered DLL in a different location
3. Create a new AppDomain and load the altered DLL

I think the only way you can do this without an app-restart is probably to hit the machine code that has been pushed out by the JIT; but then you're going to have a lot of fun actually finding the stuff you're looking for, not to mention dealing with changed types as well as all the various JIT optimizations that occur. Then you have to think about how you'd deal with dynamic code generation (there's more of it than you might think) and dynamic methods that can be garbage collected.

You might as well write your own .Net host + JIT; but then I doubt you'd persuade anyone to run it knowingly.

You certainly are not going to be able to modify the IL of the loaded assembly because .Net protects that once it's loaded. I suppose it's possible some nasty (emphasis on nasty there) low-level app that bypasses .Net completely might be able to hack the IL in memory; but I doubt the in-memory representation when loaded for execution is the same as it is on disk; and even if it is by the time you've 'hacked' it it's probably been JITted anyway and so any of your changes would make no difference.

Ultimately .Net is specifically designed to prevent what you're talking about doing. You can attach (static) dynamic methods to existing types etc to benefit from visibility (if you have permission) - but modifying loaded code? No.

As a couple of other answers have mentioned you typically do this with an assembly on disk and there are numerous tools for doing that.

But then what are you going to do about assemblies that are strong-named? You have to be able to resign them with the same strong name key that was used originally; and somehow I doubt you'll have access to that.

I can edit a .NET DLL's instructions to add my method calls.

Good for you! I don't know how you do it.

do you think it might be possible to unload the target DLL, edit it, and reload the target DLL?

No. Loaded DLL cannot be unloaded or reloaded. period.

EDIT

I was reminded that DLL can be unloaded, if you unload the whole of AppDomain. But I believe this is not what you want to do.