Logo
My Account |  Site Map | Contact Us  
Welcome Guest Search | Active Topics | Sign In | Register

How to Use EasyHook For function send in ws2_32.dll Options
171262221
Posted: Sunday, March 10, 2019 10:42:05 AM
Rank: Newbie
Groups: Member

Joined: 3/7/2019
Posts: 2
Hi,
We're going to buy EO.WebBrowser. But when we test the last item, we can't pass it. Our requirement is to be able to use EasyHook component to monitor the three functions of send, recv and WSASend in ws2_32.dll. Other browsers such as IE and CEF can be used, but EO. WebBrowser can't. I don't know where we are doing wrong. Please help me. Thank you.
eo_support
Posted: Sunday, March 10, 2019 12:52:24 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,292
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!
171262221
Posted: Sunday, March 10, 2019 1:33:19 PM
Rank: Newbie
Groups: Member

Joined: 3/7/2019
Posts: 2
Thank you for your reply.

Unfortunately, our current project has very mature API Hook applications for WebBrowser and CefSharp, which we redeveloped ourselves. It is undeniable that your products are very good, but if you want to use EO. WebBrowser, you need to re-implement API hook in ws2_32.dll. Method #1, our programmers are not familiar with this, and do not know if there are alternative solutions or you. A virtual ws2_32.dll has been written for this product. We can buy and use it directly. Thank you.
eo_support
Posted: Sunday, March 10, 2019 9:26:06 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 21,292
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!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.