Hi,

We won't be able to provide support on how to use another third party library with our product, especially some low level library such as API hook that can potentially interfere with our library. However we can provide some implementation details to you that may help you to troubleshoot or resolve the issue on your end.

There are a few key difference between our product and other products on the market:

1. We run the browser engine inside a separate child process, not in your process. So if you install hook in your own process, you won't be able to catch anything since the browser engine is not running in your own process at all. By default we use Windows's rundll32.exe to host the browser engine. However you can use our own eowp.exe process to host it as well:

https://www.essentialobjects.com/doc/common/eowp.aspx

2. We do not load the browser engine code with the normal Windows DLL loading mechanism. Instead the native browser engine code is packed inside our .NET DLLs and dynamically loaded at runtime. For a "normal" solution you would have native DLL such as "browser_engine.dll" that statically linked to "ws2_32.dll" and then "browser_engine.dll" would be loaded into your process with standard Windows LoadLibrary API. LoadLibrary would establish a jumping table (commonly called Import Address Table - IAT) for "browser_engine.dll" that contains function pointers to all "ws_32.dll" functions used by "browser_engine.dll". Many hook mechanism works by replacing this jumping table to route the call into the hooks first. This normal loading process does not occur with our product because we do not have any physical umanaged DLLs. So if your hook mechanism relies on this then it won't work.

There are several alternatives for hook to work with our product:

1. Create a dummy ws2_32.dll that exports all the function that you wish to intercept and place this library inside your application folder. This will cause this dummy DLL instead of the real DLL to be loaded. You can then add code in your dummy DLL to perform necessary interception and calls the actual implementation inside the real ws2_32.dll if necessary;

2. Instead of modifying IAT, you can use a hook implementation that modifies the code inside the target DLL directly (in your case ws2_32.dll, only the in memory copy is modified, not the physical file obviously) to intercept the call. This works by overwriting the beginning of each function with a short "detour" stub (you will need to save the original code that you overwrote), inside the stub you can perform your own interception and then call the original code to perform the original function. This method is much more cumbersome and may not work with all functions as it highly depends on the code sequence at the beginning of the function that is to be overwritten since not all code sequence can be safely broken into pieces and shuffled around. However it can work surprising good with many Windows APIs because many Windows API implementation are merely very simple standard stub code that calls into window kernel (which is protected and can't be tampered with). Chromium project uses this method to intercept a few APIs and you can find the source code here to get an idea of how this works:

https://cs.chromium.org/chromium/src/base/win/com_init_check_hook.cc

For a reliable solution, I would recommend you to use method #1. If you run into issues while trying to implement this method, we can work with you to make sure your interception code is called.

Thanks!

Hi,

I do not quite understand your reply. If you have already written a virtual ws2_32.dll then you should be able to use it. As mentioned, we can provide implementation details to you if that helps. So if you have any specific questions about our previous reply please ask. If you prefer to buy a third party library please feel free to forward our explanation to them and see what they can do.

Thanks!