These are chat archives for EasyHook/EasyHook

23rd
May 2017
Philip Heber
@pheber16_twitter
May 23 2017 08:42

Hi, in the documentation for the LocalHook Dispose method it says that a disposed hook will / may consume memory for the process life-time. In our scenario, we need to hook certain methods only for very short amounts of time. Up until now, we did this by always uninstalling (disposing) the hook after use and creating a new one on demany. However, now I'm thinking this might be an issue if hooks don't get disposed properly and may leak memory.

Is there a "correct" way to completely uninstall a hook in this scenario or do we need some sort of centralized hook management which actually keeps the hook alive and only disables it when we don't use it (i.e. using in inclusive ACL on a nonexistent thread id or something like that), which is most of the time?

Justin Stenning
@spazzarama
May 23 2017 11:00
I would use the ACLs to disable the hooks and keep them managed elsewhere
@pheber16_twitter there is also a Lh wait for hook removal which forces a cleanup (sorry on the
Justin Stenning
@spazzarama
May 23 2017 11:19
@pheber16_twitter sorry on the phone this site doesn't work so well :) What I meant is that you can call NativeAPI.LhWaitForPendingRemovals to clean up disposed hooks. This will attempt to restore the original method etc.
this has a performance hit, so I would use ACLs if you are frequently hooking/unhooking
Nikolaj Mariager
@TinkerWorX
May 23 2017 18:20
@spazzarama Oh, so you're saying that the trampoline added by EasyHook already should work if injected in the middle of a function like this?
Hmm, I could try and inject and then look at the assembly in the region, see why it just crashes.
Nikolaj Mariager
@TinkerWorX
May 23 2017 18:28
Interesting.
I see my code called, so it breaks upon returning from my code.
How much space is needed for the trampoline? Might be messing up because it's right before a switch. Any relational jumps will be broken.
Nikolaj Mariager
@TinkerWorX
May 23 2017 18:35
Alright, the trampoline is just 5 bytes for a jump, which makes sense.
Nikolaj Mariager
@TinkerWorX
May 23 2017 18:50
I'm not sure what the problem is then, if you preserve the registers.
Creating a reproducible example isn't straight forward since I'm injecting into code that isn't my own, so creating the right conditions will be next to impossible.
Philip Heber
@pheber16_twitter
May 23 2017 21:18
Alright, I guess we'll go with the ACLs, then :) - but thanks for the hint about LhWait...!
One more question if I may - as we're using EasyHook in a plugin context (i.e. we have plugins using EasyHook), we might run into a situation where two plugins inside the same process (but different .NET AppDomains) attempt to hook the same native function at the same time. Would that be supported by EasyHook?
Nikolaj Mariager
@TinkerWorX
May 23 2017 21:20
Any particular reason you have them in different AppDomains?
Unless you're sandboxing things, that shouldn't be needed
Philip Heber
@pheber16_twitter
May 23 2017 21:26

In fact we are sandboxing things, or more precisely, we are being sandboxed. We're developing two separate plugins for the same host application which live in the same process but get loaded into different AppDomains by the host (something we have little to no control over). These two plugins will both need to hook the same native method and if we're keeping the hook alive for a long time and just using ACLs to disable it (as was suggested above), both addins will almost certainly be attempting to hold a hook to the method at the same time.

We could of course implement some synchronization via remoting between the AppDomains if that's required, but if EH supports two hooks to the same method in the same process we can keep our addins decoupled as they should be.

Nikolaj Mariager
@TinkerWorX
May 23 2017 21:27
Hm, but if you allow hooking, how are you going to keep things sandboxed?
If the process/AppDomain has privilege enough to modify executable memory, it's pretty much not sandboxed anymore.
Philip Heber
@pheber16_twitter
May 23 2017 21:29
We are not sandboxing anything :). We don't control the host, we simply provide two different plugins that the host (which is not our application) will load into different AppDomains (I think more for isolation reasons than for sandboxing, really). And both plugins will use hooking for some functionality and will need to hook the same method.
Nikolaj Mariager
@TinkerWorX
May 23 2017 21:29
Ah
Peculiar to load into different app domains :P In my experience it just creates headaches with no gain.
But if it's out of your control, that's what you have to deal with.
Philip Heber
@pheber16_twitter
May 23 2017 21:30
indeed :)