COMHookingBasis sample difficult to get running

[bo3b]

When I build and run the COMHookingBasis C# sample in Visual Studio 2013, I never hit the breakpoint on OnDllGetClassObjectCalled.

I hit other breakpoints, so the connection to debugger is correct.

This along with other tests makes me think that the

            hookDllGetClassObj.OnFunctionCalled += OnDllGetClassObjectCalled;

is not functional. I tested on both Win7 and Win10, neither work. No errors are reported.

Adding a handler to the SpyMgr itself seems to work, but hook specific call handlers do not get called.

[bo3b]

OK, got it working. Not broken. Works in VS2013.

Basic problem is the complete lack of documentation, which makes getting anything to run quite a challenge.

This sample dumps its results in the ./bin directory, and if any pieces are missing it will silently fail. No error results, no exceptions, no info.

There are also undocumented dependencies on the assorted Deviare items in bin. If you are missing anything like the deviare*.db files, or DeviareCOM, or DvAgent, or Nektra.Deviare2.dll- then you get nothing, and no way to debug it.

Please! Documentation could have saved me a full week of trouble.

Deviare and in-proc are solid solutions. I humbly suggest that the only reason Deviare is lagging in comparison to MinHook is because the absence of any documentation makes it very difficult to get it setup.

1. The Samples are too incestuous with the Deviare2 code itself, and should work standalone, with required binaries attached. I need to be able to download a sample, and have it work.
2. Explanation of the Agent would be in order. It took me a long time to understand that the Agent and MyRegistryPlugin are not the same, and do different jobs.
3. Architecture is a mystery. I can do OnFunctionCalled for SpyMgr, Process, and Hook. Why? Tradeoffs, and reasoning why cannot be found when the only resource is undocumented code. Code answers 'what', not 'why'.
4. Better pre-flight/setup/error handling. There is no excuse for silent failures when files are missing. If there were documentation on dependencies and requirements, this would possibly be OK.
5. Code samples are far too complex without any supporting documentation. The COMHookingBasis has a series of mystery GUIDs, with zero output. It's not clear how it works, or what it does, or even how to activate that part.
6. The Forums! Why are they still dead!!! Much documentation lost!!!

[bo3b]

Actually, this cost me an entire week, so I'm leaving this open for anyone else who comes along and tries to use this.

[Helios-vmg]

Explanation of the Agent would be in order.

DvAgent is the DLL that gets injected into the remote process. It's the thing that actually performs the operations you request in the hooking process.

I can do OnFunctionCalled for SpyMgr, Process, and Hook. Why?

Without knowing anything else, I would assume that handling OnFunctionCalled from the hook object notifies you when the hooked function is called, handling it from the process object notifies you when any hooked function in the process is called, and handling it from the spy manager notifies you when any hooked function anywhere is called. Granted, you do need to know what the spy manager is, which is not documented anywhere that I know, but it's not really unintuitive.

The COMHookingBasis has a series of mystery GUIDs, with zero output. It's not clear how it works, or what it does, or even how to activate that part.

I agree that those GUIDs should have been hidden behind named constants, but the comment above does say "check if we are creating an instance that belongs to [...] 'IShellFolderViewDual'". If you google those GUIDs you can see that they're for three IShellFolderViewDual-related interfaces.

[bo3b]

Thank you for responding. That gives me enough confidence to move forward with my project.

The COMHookingBasis sample shows a good example of how to create a hook for vtable based function. But doesn't actually do anything with the data or the hook. It would be a stronger sample if it used the connected Console.WriteLn to output what is happening, and details of the returned results. Somebody had something in mind with using NotePad here, but the results are inscrutable to me. I don't even know what to do in NotePad to activate the code.

I'm a graphics guy, and I don't know that much about other parts of Win32 programming, so the IShellFolderViewDual interface doesn't mean anything to me without research. It wasn't until quite a bit later that I discovered that it would trigger based on the Open File in Notepad.

This is what I mean by answering the why. This examples exists to demonstrate hooking the vtable and get results back from the hooked params. But there is not even any header comment to describe the sample and why it exists. Without some dedication, I think no one will take that time to understand it. I've personally found in-proc to be really solid, which is why I persisted in trying to understand Deviare.

Since you are still actively engaged with this project, I will put together a Deviare sample myself, that will demonstrate what I think makes for a good sample. I'll send a pull request when it's ready.

[Helios-vmg]

That will be much appreciated.

[bo3b]

I built a full sample app that I feel explains how to use Deviare better than your current samples. I say this as a person who just spent several weeks trying to understand how to use the tool, and I think your current documentation is not sufficient for newcomers.

Deviare and In-Proc themselves are excellent. Once I understand how to use them, they are powerful and reliable. It's just that the learning curve is so steep that I really almost gave up. I'm sure other people just give up.

What I'm expecting is a sample that I can download and either build or run without having to do anything else. Having to understand the funny structure of a ./bin that is outside of the sample directories is confusing and strange for newbies.

It doesn't really make sense for this sample to be added as pull-request, because it does not follow your model of having all your samples access the ./bin directory. I can make a good argument for your model if you were to add the needed binaries there in the repo, and not require me to build them. If that model is used, this sample would fit in.

Building the tool as a first step is fraught with peril, and did not work without me having to jump through a lot of hoops for installing different tools and packages. Running the samples were always failing because there was no documentation on how to actually get them to work, including that crucial regsvr32 step.

Running the samples would always fail, building would fail, nothing seemed to work at all. I finally backed all the way up to running your CSharpConsole app directly from the 2.8.3 binaries and that worked. That allowed me to follow the trail back to getting it to compile and also run properly. I don't think anyone else will spend the week it took me to figure all this out.

As an immediate suggestion- put a Git Submodule link to your Deviare.2.8.3 repo, as the ./bin folder. That way when I properly checkout with --recursive, I would be all ready to go. Then the Build.Bat can also elevate privileges, and do the rgsvr32 as part of the build. That would call out the need for regsvr32, and lower the friction of getting all this to work.

In any case, I think my sample is complete, please feel free to use this Repo however you see fit:
https://github.com/bo3b/Hooking-DX9-Present

Add to your nektra based samples, add to your Deviare repo samples, take over the copyright, change the license. Anything you prefer is OK with me, I just wanted to contribute some badly needed documentation.